Re: 13.1 from main?

[Steve Wills]

Hi,

On 4/22/21 6:00 PM, Alan Somers wrote:

Because we have a policy of never releasing anything even a little bit
backwards-incompatible in a minor release.


I believe we have made backwards incompatible changes in minor branches 
in the fairly recent past, at least compiler changes and VM changes that 
affected video drivers. But I'm not sure, please correct me if I'm wrong.


Cheers,

Steve


___
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: webcamd not started automatically

[Steve Wills]

Hi,

On 2/18/21 9:14 AM, Jakob Alvermark wrote:
It used to start webcamd for both of them, now it is only started for 
the built in Chicony.


I have a similar problem. I have 3 cameras (one Logitech and two USB UVD 
things) and now it only starts webcamd for one. I can start it manually 
for the other two. I don't have the details now, but it seemed like when 
I started it for the second or third device, it said it was already 
running until I tried again.


Thanks,

Steve


___
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: Please check the current beta git conversions

[Steve Wills]

Hi,

On 9/1/20 1:14 PM, Ed Maste wrote:

We've been updating the svn-git converter and pushing out a new
converted repo every two weeks, and are now approaching the time where
we'd like to commit to the tree generated by the exporter, and
guarantee that hashes will remain consistent from this point. At this
point the Git Working Group believes the conversion represents a
high-fidelity translation of the Subversion history, but would
appreciate additional review in case we've missed anything.

I'd ask folks with an interest in the FreeBSD repository to clone the
beta conversion and review the converted history in the specific areas
they are interested in - e.g., specific contrib/ software, device
drivers, etc. This will also present our final opportunity to change
the author map file, if necessary.

The beta src tree can be cloned via:
% git clone https://cgit-beta.freebsd.org/src.git freebsd-cgit-beta

Please follow up this week if you notice any discrepancies or author
entries that require updates.


One issue that's been seen is adding this remote to an existing repo:

$ git remote add cgit-beta https://cgit-beta.freebsd.org/ports.git
$ git fetch cgit-beta
error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413
fatal: the remote end hung up unexpectedly

413 is Payload too large

This is because when you fetch, you're telling the other end what hashes 
you have and it's figuring out what to send you, and that list is too 
large, over 10m, I guess:


https://stackoverflow.com/questions/7489813/github-push-error-rpc-failed-result-22-http-code-413#15021750

It's unclear if there's a way to tell the client to skip that and just 
fetch everything or if it's required to change the upload limit on the 
web server and if so how large would be appropriate/required.


Note fresh clone works fine.

Steve
___
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: svn commit: r352558 - head/usr.bin/top

[Steve Wills]

Hi,

On 7/10/20 7:12 PM, Yuri Pankov wrote:



Thanks.

The attached diff seems to take care of the issue for me, adding VIS_TAB 
and removing VIS_SAFE, which can be blamed for passing through the 
following:


VIS_SAFE   Currently this form allows space, tab, newline, backspace,
    bell, and return — in addition to all graphic characters —
    unencoded.


That does seem to fix it for me. Please commit. :)

Thanks,
Steve
___
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: svn commit: r352558 - head/usr.bin/top

[Steve Wills]

On 11/28/19 4:08 PM, Mark Millard via svn-src-head wrote:

Author: daichi
Date: Fri Sep 20 17:37:23 2019
New Revision: 352558
URL:
https://svnweb.freebsd.org/changeset/base/352558


Log:
   top(1): support multibyte characters in command names (ARGV array)
   depending on locale.
   
- add setlocale()

- remove printable() function
- add VIS_OCTAL and VIS_SAFE to the flag of strvisx() to display
  non-printable characters that do not use C-style backslash sequences
  in three digit octal sequence, or remove it
   
   This change allows multibyte characters to be displayed according to

   locale. If it is recognized as a non-display character according to the
   locale, it is displayed in three digit octal sequence.



Initially picking on tab characters as an example of what is
probably a somewhat broader issue . . .

Ever since this change, characters like tabs that do not fit
in the next character cell when output, but for which they
are !isprintable(...), now mess up the top display. Again
using tab as an example: line wrapping from the text having
been shifted over by more than one character cell. top does
not track the line wrapping result in how it decides what
to output for the following display updates.



Apologies for the way late reply here, but I just now bothered tracking 
this down. This commit seems to be the cause of some corruption I'm 
seeing in long running top(1) as well. As Mark mentions, if I use "hh" 
it clears up. Should I open a bugzilla bug? I can share screenshots of 
the corruption, such as:


https://i.imgur.com/Xqlwf9h.png
https://i.imgur.com/Jv0d5NU.png

Thanks,
Steve
___
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: ESXi NFSv4.1 client id is nasty

[Steve Wills]

Hi,

On 06/18/18 17:42, Rick Macklem wrote:

Steve Wills wrote:

Would it be possible or reasonable to use the client ID to log a message
telling the admin to enable a sysctl to enable the hacks?

Yes. However, this client implementation id is only seen by the server
when the client makes a mount attempt.

I suppose it could log the message and fail the mount, if the "hack" sysctl 
isn't
set?


I hadn't thought of failing the mount, just defaulting not enabling the 
hacks unless the admin chooses to enable them. But at the same time 
being proactive about telling the admin to enable them.


I.E. keep the implementation RFC compliant since we wouldn't be changing 
the behavior based on the implementation ID, only based upon the admin 
setting the sysctl, which we told them to do based on the implementation ID.


Just an idea, maybe Warner's suggestion is a better one.

Steve


___
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: ESXi NFSv4.1 client id is nasty

[Steve Wills]

Would it be possible or reasonable to use the client ID to log a message 
telling the admin to enable a sysctl to enable the hacks?


Steve

On 06/17/18 08:35, Rick Macklem wrote:

Hi,

Andreas Nagy has been doing a lot of testing of the NFSv4.1 client in ESXi 6.5u1
(VMware) against the FreeBSD server. I have given him a bunch of hackish patches
to try and some of them do help. However not all issues are resolved.
The problem is that these hacks pretty obviously violate the NFSv4.1 RFC (5661).
(Details on these come later, for those interested in such things.)

I can think of three ways to deal with this:
1 - Just leave the server as is and point people to the issues that should be 
addressed
  in the ESXi client.
2 - Put the hacks in, but only enable them based on a sysctl not enabled by 
default.
  (The main problem with this is when the server also has non-ESXi mounts.)
3 - Enable the hacks for ESXi client mounts only, using the implementation ID
  it presents at mount time in its ExchangeID arguments.
  - This is my preferred solution, but the RFC says:
An example use for implementation identifiers would be diagnostic
software that extracts this information in an attempt to identify
interoperability problems, performance workload behaviors, or general
usage statistics.  Since the intent of having access to this
information is for planning or general diagnosis only, the client and
server MUST NOT interpret this implementation identity information in
a way that affects interoperational behavior of the implementation.
The reason is that if clients and servers did such a thing, they
might use fewer capabilities of the protocol than the peer can
support, or the client and server might refuse to interoperate.

Note the "MUST NOT" w.r.t. doing this. Of course, I could argue that, since the
hacks violate the RFC, then why not enable them in a way that violates the RFC.

Anyhow, I would like to hear from others w.r.t. how they think this should be 
handled?

Here's details on the breakage and workarounds for those interested, from 
looking
at packet traces in wireshark:
Fairly benign ones:
- The client does a ReclaimComplete with one_fs == false and then does a
   ReclaimComplete with one_fs == true. The server returns
   NFS4ERR_COMPLETE_ALREADY for the second one, which the ESXi client
   doesn't like.
   Woraround: Don't return an error for the one_fs == true case and just assume
that same as "one_fs == false".
   There is also a case where the client only does the
   ReclaimComplete with one_fs == true. Since FreeBSD exports a hierarchy of
   file systems, this doesn't indicate to the server that all reclaims are done.
   (Other extant clients never do the "one_fs == true" variant of
   ReclaimComplete.)
   This case of just doing the "one_fs == true" variant is actually a limitation
   of the server which I don't know how to fix. However the same workaround
   as listed about gets around it.

- The client puts random garbage in the delegate_type argument for
   Open/ClaimPrevious.
   Workaround: Since the client sets OPEN4_SHARE_ACCESS_WANT_NO_DELEG, it 
doesn't
   want a delegation, so assume OPEN_DELEGATE_NONE or OPEN_DELEGATE_NONE_EXT
   instead of garbage. (Not sure which of the two values makes it happier.)

Serious ones:
- The client does a OpenDowngrade with arguments set to OPEN_SHARE_ACCESS_BOTH
   and OPEN_SHARE_DENY_BOTH.
   Since OpenDowngrade is supposed to decrease share_access and share_deny,
   the server returns NFS4ERR_INVAL. OpenDowngrade is not supposed to ever
   conflict with another Open. (A conflict happens when another Open has
   set an OPEN_SHARE_DENY that denies the result of the OpenDowngrade.)
   with NFS4ERR_SHARE_DENIED.
   I believe this one is done by the client for something it calls a
   "device lock" and really doesn't like this failing.
   Workaround: All I can think of is ignore the check for new bits not being set
   and reply NFS_OK, when no conflicting Open exists.
   When there is a conflicting Open, returning NFS4ERR_INVAL seems to be the
   only option, since NFS4ERR_SHARE_DENIED isn't listed for OpenDowngrade.

- When a server reboots, client does not serialize ExchangeID/CreateSession.
   When the server reboots, a client needs to do a serialized set of RPCs
   with ExchangeID followed by CreateSession to confirm it. The reply to
   ExchangeID has a sequence number (csr_sequence) in it and the
   CreateSession needs to have the same value in its csa_sequence argument
   to confirm the clientid issued by the ExchangeID.
   The client sends many ExchangeIDs and CreateSessions, so they end up failing
   many times due to the sequence number not matching the last ExchangeID.
   (This might only happen in the trunked case.)
   Workaround: Nothing that I can think of.

- ExchangeID sometimes sends eia_clientowner.co_verifier argument as all zeros.
   Sometimes the client bogusly 

Re: Deadlocks / hangs in ZFS

[Steve Wills]

I may be seeing similar issues. Have you tried leaving top -SHa running 
and seeing what threads are using CPU when it hangs? I did and saw pid 
17 [zfskern{txg_thread_enter}] using lots of CPU but no disk activity 
happening. Do you see similar?


Steve

On 05/22/18 04:17, Alexander Leidinger wrote:

Hi,

does someone else experience deadlocks / hangs in ZFS?

What I see is that if on a 2 socket / 4 cores -> 16 threads system I do 
a lot in parallel (e.g. updating ports in several jails), then the 
system may get into a state were I can login, but any exit (e.g. from 
top) or logout of shell blocks somewhere. Sometimes it helps to CTRL-C 
all updates to get the system into a good shape again, but most of the 
times it doesn't.


On another system at the same rev (333966) with a lot less CPUs (and AMD 
instead of Intel), I don't see such a behavior.


Bye,
Alexander.


___
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: zfskern{txg_thread_enter} thread using 100% or more CPU

[Steve Wills]

I finally caught this happening while I had "lockstat sleep 1" running 
in a loop, the output looks like:


https://gist.github.com/swills/a2a20c2a4296a4c596ec7f329fb945ab

And top looks like this:

https://gist.github.com/swills/6e749313e52679224adec91d4841ad83

Also noticed that there are actually 2 threads of pid 17 
[zfskern{txg_thread_enter}] which are reporting 57% and 42% of disk IO, 
everything else is idle as far as IO. The system is not totally 
unresponsive, processes that don't need IO are working, but anything 
that needs IO hangs. Perhaps it's a hardware issue, but I can't find any 
other evidence of it. Any ideas?


Steve

On 04/24/2018 19:30, Steve Wills wrote:

Hi,

Recently on multiple systems running CURRENT, I've been seeing the 
system become unresponsive. Leaving top(1) running has lead me to notice 
that when this happens, the system is still responding to ping and top 
over ssh is still working, but no new processes can start and switching 
to other tasks doesn't work. In top, I do see pid 17, 
[zfskern{txg_thread_enter}] monopolizing both CPU usage and disk IO. Any 
ideas how to troubleshoot this? It doesn't appear to be a hardware issue.


Steve
___
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-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

zfskern{txg_thread_enter} thread using 100% or more CPU

[Steve Wills]

Hi,

Recently on multiple systems running CURRENT, I've been seeing the 
system become unresponsive. Leaving top(1) running has lead me to notice 
that when this happens, the system is still responding to ping and top 
over ssh is still working, but no new processes can start and switching 
to other tasks doesn't work. In top, I do see pid 17, 
[zfskern{txg_thread_enter}] monopolizing both CPU usage and disk IO. Any 
ideas how to troubleshoot this? It doesn't appear to be a hardware issue.


Steve
___
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: devdmatch: Can't read linker file.

[Steve Wills]

FWIW, I ran into this issue on an i386 image I built from an amd64 host 
using poudriere and poudriere image.


Steve

On 03/13/2018 14:44, Warner Losh wrote:

Makes sense. I'd forgotten that kldxref can't do cross-platform stuff
One could arrange to build it targeting arch X but running on the native
host and fix things that way. Nobody has care enough to do that, though
perhaps this gives us a use case for why one might want to try.

Warner

On Tue, Mar 13, 2018 at 11:41 AM, Daniel Braniss 
wrote:




On 13 Mar 2018, at 19:12, Edward Napierala  wrote:

I think it's only needed for kernels that are cross-built.  That's due to
kldxref(8) being unable to handle kernels for other architectures.

my case exactly.

2018-03-13 13:34 GMT+00:00 Warner Losh :


I wonder why that isn't the default, or why the linker.hints isn't at
least
created by the make installkernel step...

Warner

On Tue, Mar 13, 2018 at 2:40 AM, Edward Tomasz Napierała <
tr...@freebsd.org>
wrote:


FWIW, it seems to be a common problem, see https://reviews.freebsd.org/
D14534.

On 0312T1027, Warner Losh wrote:

Well, is there a /boot/kernel/linker.hints?

Warner

On Mon, Mar 12, 2018 at 9:56 AM, Daniel Braniss 

wrote:



Hi,
the above i get on arm/nanopi-neo. (it’s the only platform I run

current

:-)

cheers,
 danny



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

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
"






___
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-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: Enabling NUMA in BIOS stop booting FreeBSD

[Steve Wills]

Hi,

On 12/21/2016 06:58, Konstantin Belousov wrote:
> What is the exact version of the kernel you are running and which hangs ?

Right now I'm running r310303, booted with SMP disabled.

> Try to bisect.
> 

The issue appeared without updating the OS, but I have since updated.
That said, I have tried booting 10.3 and 9.3 from USB memstick without
success.

> Do you have EARLY_AP_STARTUP option in the kernel config ?
> 

I did, but I have since tried adding nooptions EARLY_AP_STARTUP to my
kernel config (my config include's GENERIC), which didn't affect the issue.

> Send NMI with 'ipmi power diag' and show the machine state from ddb.
> 

This board is the version without ipmi support, so I unfortunately can't
do that.

Steve



signature.asc
Description: OpenPGP digital signature

Re: Enabling NUMA in BIOS stop booting FreeBSD

[Steve Wills]

Hi,

On 12/16/2016 16:20, John Baldwin wrote:
> On Thursday, December 15, 2016 03:57:58 PM Adrian Chadd wrote:
>> heh, an updated BIOS that solves the problem will solve the problem. :)
>>
>> I think you have enough information to provide to supermicro. Ie,
>> "SMAP says X, when physical memory pages at addresses X are accessed,
>> they don't behave like memory, maybe something is wrong".
>>
>> All I can think of is some hack to add a blacklist for that region so
>> you can boot the unit. But it makes me wonder what else is going on.
> 
> We have the blacklist: it is the memory test.  That is the way to workaround
> this type of BIOS breakage.  This is just the first time in over a decade that
> test has been relevant.

I've got a SuperMicro X10SRA board that I bought back in March, I think.
It was run CURRENT fine since then, until last month, when it started
hanging during boot. I was about to update it to a new version of
CURRENT when it started hanging at boot, but hadn't updated yet. The
hang is after (verbose boot):

ACPI APIC Table: 
Package ID shift: 4
L3 cache ID shift: 4
L2 cache ID shift: 1
L1 cache ID shift: 1
Core ID shift: 1

Recently I've tried booting 9.3 and 10.3 on it without success. Other
operating systems boot fine. Thinking the hang was similar to the one in
this thread (or at least the board is), I tried many different BIOS
changes and also tried enabling the memory test, but none of that
changes anything. This is a single socket board so there are no NUMA or
memory interleaving options in the BIOS. The BIOS is up to date (2.0a).
It will boot if SMP is disabled. That's obviously sub-optimal, but is
useful for building updated kernels, which I've tried. If anyone has any
suggestions or ideas, I'd appreciate it.

Thanks,
Steve



signature.asc
Description: OpenPGP digital signature

Re: wired memory leak at r298785

[Steve Wills]

On 05/ 2/16 11:24 PM, Warner Losh wrote:
> 
> 
> On Mon, May 2, 2016 at 6:55 PM, Steve Wills <swi...@freebsd.org
> <mailto:swi...@freebsd.org>> wrote:
> 
> Hi,
> 
>     On 05/ 2/16 09:32 AM, Steve Wills wrote:
> > Hi,
> >
> > Just did my monthly update and r298785 seems to be leaking wired
> memory
> > rather rapidly. My system has 8gb of RAM and the amount of wired
> memory
> > just goes up and up continuously. It takes about 12 hours before it
> > exhausts all the RAM and sort of locks up (though shutdown still
> works).
> >
> > I also made one other change to the system at the same time as
> updating,
> > which was to add another disk and configure it using ZFS. Perhaps this
> > is a ZFS on PowerPC64 issue? My amd64 box running the same rev of
> > CURRENT doesn't have the issue.
> >
> 
> I've rebooted the box and started repeatedly logging the output of
> vmstat -m. It seems to show CAM CCB using a lot of memory and growing
> rather rapidly. For example, here's a few lines of diff output:
> 
> - CAM CCB 91418 182836K - 187149 2048
> + CAM CCB 447070 894140K - 900292 2048
> 
> from two samples that are 60 minutes apart.
> 
> The box is isn't terribly busy, it's just running the monitoring daemons
> running (snmpd, collectd), whatever web requests are hitting it (very
> few if any), this logging process, and my shell, etc.
> 
> Could this be related to recent changes in CURRENT?
> 
> Copying Scott and Warner in case they have comments on this since I'm
> told they have been active in this area recently.
> 
> 
> I've been looking into it. I'm not sure what's up since I don't see it
> in production. I'll give it a bump in priority though.
> 

Thanks! I did notice that killing bsnmpd drastically slowed the rate of
growth, but didn't completely eliminate it.

Steve
___
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: wired memory leak at r298785

[Steve Wills]

Hi,

On 05/ 2/16 09:32 AM, Steve Wills wrote:
> Hi,
> 
> Just did my monthly update and r298785 seems to be leaking wired memory
> rather rapidly. My system has 8gb of RAM and the amount of wired memory
> just goes up and up continuously. It takes about 12 hours before it
> exhausts all the RAM and sort of locks up (though shutdown still works).
> 
> I also made one other change to the system at the same time as updating,
> which was to add another disk and configure it using ZFS. Perhaps this
> is a ZFS on PowerPC64 issue? My amd64 box running the same rev of
> CURRENT doesn't have the issue.
> 

I've rebooted the box and started repeatedly logging the output of
vmstat -m. It seems to show CAM CCB using a lot of memory and growing
rather rapidly. For example, here's a few lines of diff output:

- CAM CCB 91418 182836K - 187149 2048
+ CAM CCB 447070 894140K - 900292 2048

from two samples that are 60 minutes apart.

The box is isn't terribly busy, it's just running the monitoring daemons
running (snmpd, collectd), whatever web requests are hitting it (very
few if any), this logging process, and my shell, etc.

Could this be related to recent changes in CURRENT?

Copying Scott and Warner in case they have comments on this since I'm
told they have been active in this area recently.

Thanks,
Steve
___
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: zfs hang

[Steve Wills]

On Wed, Oct 08, 2014 at 08:55:26AM +0300, Andriy Gapon wrote:
 On 08/10/2014 03:40, Steve Wills wrote:
  Hi,
  
  Not sure which thread this belongs to, but I have a zfs hang on one of my 
  boxes
  running r272152. Running procstat -kka looks like:
  
  http://pastebin.com/szZZP8Tf
  
  My zpool commands seem to be hung in spa_errlog_lock while others are hung 
  in
  zfs_lookup. Suggestions?
 
 There are several threads in zio_wait.  If this is their permanent state then
 there is some problem with I/O somewhere below ZFS.

Thanks for the feedback. It seems one of my disks is dying, I rebooted and it
came up OK, but today I got:

  panic: I/O to pool 'rpool' appears to be hung on vdev guid . at 
'/dev/ada0p3'

I have screenshots and backtrace if anyone is interested. Dying drives
shouldn't cause panic, right?

Steve
___
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 hang

[Steve Wills]

On Fri, Oct 10, 2014 at 02:35:14AM +0100, Steven Hartland wrote:
 
 - Original Message - 
 From: Steve Wills swi...@freebsd.org
 To: Andriy Gapon a...@freebsd.org
 Cc: curr...@freebsd.org; f...@freebsd.org
 Sent: Friday, October 10, 2014 2:27 AM
 Subject: Re: zfs hang
 
 
  On Wed, Oct 08, 2014 at 08:55:26AM +0300, Andriy Gapon wrote:
  On 08/10/2014 03:40, Steve Wills wrote:
   Hi,
   
   Not sure which thread this belongs to, but I have a zfs hang on one of 
   my boxes
   running r272152. Running procstat -kka looks like:
   
   http://pastebin.com/szZZP8Tf
   
   My zpool commands seem to be hung in spa_errlog_lock while others are 
   hung in
   zfs_lookup. Suggestions?
  
  There are several threads in zio_wait.  If this is their permanent state 
  then
  there is some problem with I/O somewhere below ZFS.
  
  Thanks for the feedback. It seems one of my disks is dying, I rebooted and 
  it
  came up OK, but today I got:
  
   panic: I/O to pool 'rpool' appears to be hung on vdev guid . at 
  '/dev/ada0p3'
  
  I have screenshots and backtrace if anyone is interested. Dying drives
  shouldn't cause panic, right?
 
 Its the deadman timer kicking in so yes, thats expected.
 
 The following sysctls control this behaviour if you want to try and recover:
 vfs.zfs.deadman_synctime_ms: 100
 vfs.zfs.deadman_checktime_ms: 5000
 vfs.zfs.deadman_enabled: 1

Ah, ok. This pool has two disks, mirrored. I think one of them is dying, the
BIOS gives a SMART error on startup, but it still uses the disk fine. From what
I read of the zfs deadman design, it's for when the controller is acting up. So
I'm confused. Maybe this means both disks are dying?

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

zfs hang

[Steve Wills]

Hi,

Not sure which thread this belongs to, but I have a zfs hang on one of my boxes
running r272152. Running procstat -kka looks like:

http://pastebin.com/szZZP8Tf

My zpool commands seem to be hung in spa_errlog_lock while others are hung in
zfs_lookup. Suggestions?

Thanks,
Steve
___
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

network hang using intel em nic

[Steve Wills]

Hi,

I've got some new hardware and have been experiencing lockups using the em
driver. They seem to only happen on large downloads, smaller things like ssh
and web browsing work OK. The hardware is:

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

I did have the vboxnet driver loaded, but tried unloading that and still saw
the issue. One thing I notice is some garbage at the top of the screen when the
hang happens, perhaps there's a conflict with the vesa video. (This system is
Haswell, using the vga/vesa driver.)

Any suggestions on how to debug?

Thanks,
Steve
___
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: network hang using intel em nic

[Steve Wills]

On Mon, Sep 08, 2014 at 01:29:31PM -0400, Allan Jude wrote:
 
 Try periodically setting dev.em.0.debug=1
 
 it will dump a bunch of stats to syslog then set it self back to -1
 
 there are also a bunch of useful stats under:
 dev.em.0 including things like:
 dev.em.0.mbuf_alloc_fail
 dev.em.0.watchdog_timeouts
 dev.em.0.mac_stats.collision_count
 
 etc
 
 that might provide some insight.
 
 I have a box with 4x of the i210 (but that shows up as igb(4))
 
 I have one of the i217LM nics in this machine, but it is used for video
 production so it isn't running BSD at the moment.

Thanks for the suggestions, I think I may have solved it just by ensuring my
kernel modules for vbox and cuse were in sync with the kernel.

Steve
___
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: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction

[Steve Wills]

Hi,

On Thu, Jul 31, 2014 at 06:22:27PM +0200, Anton Berezin wrote:
 Jan,
 
 On Thu, Jul 31, 2014 at 05:56:23PM +0200, Jan Kokemüller wrote:
  On 31.07.2014 16:21, Anton Berezin wrote:
  At the console, depressing and holding a key does not lead to auto-repeat.
  
  At the console, sometimes a key only appears on the terminal after another
  key is pressed.
  
  Maybe this is a problem caused by a misdetected clock source? I've had this
  problem as well.
  
  Try to set kern.timecounter.hardware and/or kern.eventtimer.timer to other
  settings that are listed in kern.timecounter.choice and
  kern.eventtimer.choice, such as HPET which works great for me.
 
 Setting both to HPET certainly helped the LA.  I cannot check the keyboard
 input until tomorrow, but chances are that it is indeed the fix.

Just wanted to throw in another datapoint, I had this issue too and setting
kern.eventtimer.timer=HPET alone solved it for me.

Steve


pgpj6dqznjoLq.pgp
Description: PGP signature

tmpfs panic

[Steve Wills]

Hi,

Just experienced this tmpfs panic on r268160:

Freed UMA keg (TMPFS node) was not empty (16 items).  Lost 1 pages of memory.


Fatal trap 12: page fault while in kernel mode
cpuid = 12; apic id = 0c
fault virtual address   = 0x378
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x809638d1
stack pointer   = 0x28:0xfe07243800a0
frame pointer   = 0x28:0xfe0724380120
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 65339 (pkg-static)
[ thread pid 65339 tid 101641 ]
Stopped at  __mtx_lock_sleep+0xb1:  movl0x378(%rax),%ecx
db bt
Tracing pid 65339 tid 101641 td 0xf80286b2e490
__mtx_lock_sleep() at __mtx_lock_sleep+0xb1/frame 0xfe0724380120
free_unr() at free_unr+0x9d/frame 0xfe0724380160
tmpfs_free_node() at tmpfs_free_node+0xf2/frame 0xfe07243801a0
tmpfs_reclaim() at tmpfs_reclaim+0xdc/frame 0xfe07243801d0
VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xa7/frame 0xfe0724380200
vgonel() at vgonel+0x24c/frame 0xfe0724380280
vrecycle() at vrecycle+0x84/frame 0xfe07243802c0
tmpfs_inactive() at tmpfs_inactive+0x18/frame 0xfe07243802d0
VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0xa7/frame 0xfe0724380300
vinactive() at vinactive+0x181/frame 0xfe0724380360
vputx() at vputx+0x30d/frame 0xfe07243803d0
vn_close() at vn_close+0x13e/frame 0xfe0724380450
vn_closefile() at vn_closefile+0x48/frame 0xfe07243804d0
_fdrop() at _fdrop+0x29/frame 0xfe07243804f0
closef() at closef+0x2ae/frame 0xfe0724380580
fdescfree() at fdescfree+0x64c/frame 0xfe0724380630
exit1() at exit1+0x682/frame 0xfe07243806c0
sigexit() at sigexit+0x929/frame 0xfe0724380980
postsig() at postsig+0x3c4/frame 0xfe0724380a70
ast() at ast+0x487/frame 0xfe0724380ab0
doreti_ast() at doreti_ast+0x1f/frame 0x7fffc6e0
db 

Any further debugging I can do?

Thanks,
Steve


pgp1crx2RWpBD.pgp
Description: PGP signature

Re: tmpfs panic

[Steve Wills]

I should have noted this system is running in bhyve. Also I'm told this panic
may be related to the fact that the system is running in bhyve.

Looking at it a little more closely:

(kgdb) list *__mtx_lock_sleep+0xb1
0x809638d1 is in __mtx_lock_sleep (/usr/src/sys/kern/kern_mutex.c:431).
426  * owner stops running or the state of the lock changes.
427  */
428 v = m-mtx_lock;
429 if (v != MTX_UNOWNED) {
430 owner = (struct thread *)(v  ~MTX_FLAGMASK);
431 if (TD_IS_RUNNING(owner)) {
432 if (LOCK_LOG_TEST(m-lock_object, 0))
433 CTR3(KTR_LOCK,
434 %s: spinning on %p held by 
%p,
435 __func__, m, owner);
(kgdb) 

I'm told that MTX_CONTESTED was set on the unlocked mtx and that MTX_CONTENDED
is spuriously left behind, and to ask how lock prefix is handled in bhyve. Any
of that make sense to anyone?

Thanks,
Steve

On Sun, Jul 06, 2014 at 01:53:37PM +, Steve Wills wrote:
 Hi,
 
 Just experienced this tmpfs panic on r268160:
 
 Freed UMA keg (TMPFS node) was not empty (16 items).  Lost 1 pages of memory.
 
 
 Fatal trap 12: page fault while in kernel mode
 cpuid = 12; apic id = 0c
 fault virtual address   = 0x378
 fault code  = supervisor read data, page not present
 instruction pointer = 0x20:0x809638d1
 stack pointer   = 0x28:0xfe07243800a0
 frame pointer   = 0x28:0xfe0724380120
 code segment= base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags= interrupt enabled, resume, IOPL = 0
 current process = 65339 (pkg-static)
 [ thread pid 65339 tid 101641 ]
 Stopped at  __mtx_lock_sleep+0xb1:  movl0x378(%rax),%ecx
 db bt
 Tracing pid 65339 tid 101641 td 0xf80286b2e490
 __mtx_lock_sleep() at __mtx_lock_sleep+0xb1/frame 0xfe0724380120
 free_unr() at free_unr+0x9d/frame 0xfe0724380160
 tmpfs_free_node() at tmpfs_free_node+0xf2/frame 0xfe07243801a0
 tmpfs_reclaim() at tmpfs_reclaim+0xdc/frame 0xfe07243801d0
 VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xa7/frame 0xfe0724380200
 vgonel() at vgonel+0x24c/frame 0xfe0724380280
 vrecycle() at vrecycle+0x84/frame 0xfe07243802c0
 tmpfs_inactive() at tmpfs_inactive+0x18/frame 0xfe07243802d0
 VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0xa7/frame 0xfe0724380300
 vinactive() at vinactive+0x181/frame 0xfe0724380360
 vputx() at vputx+0x30d/frame 0xfe07243803d0
 vn_close() at vn_close+0x13e/frame 0xfe0724380450
 vn_closefile() at vn_closefile+0x48/frame 0xfe07243804d0
 _fdrop() at _fdrop+0x29/frame 0xfe07243804f0
 closef() at closef+0x2ae/frame 0xfe0724380580
 fdescfree() at fdescfree+0x64c/frame 0xfe0724380630
 exit1() at exit1+0x682/frame 0xfe07243806c0
 sigexit() at sigexit+0x929/frame 0xfe0724380980
 postsig() at postsig+0x3c4/frame 0xfe0724380a70
 ast() at ast+0x487/frame 0xfe0724380ab0
 doreti_ast() at doreti_ast+0x1f/frame 0x7fffc6e0
 db 
 
 Any further debugging I can do?
 
 Thanks,
 Steve




pgpUHP9rv_17p.pgp
Description: PGP signature

Re: tmpfs panic

[Steve Wills]

On Sun, Jul 06, 2014 at 12:28:07PM -0400, Ryan Stone wrote:
 On Sun, Jul 6, 2014 at 11:46 AM, Steve Wills swi...@freebsd.org wrote:
  I should have noted this system is running in bhyve. Also I'm told this 
  panic
  may be related to the fact that the system is running in bhyve.
 
  Looking at it a little more closely:
 
  (kgdb) list *__mtx_lock_sleep+0xb1
  0x809638d1 is in __mtx_lock_sleep 
  (/usr/src/sys/kern/kern_mutex.c:431).
  426  * owner stops running or the state of the lock 
  changes.
  427  */
  428 v = m-mtx_lock;
  429 if (v != MTX_UNOWNED) {
  430 owner = (struct thread *)(v  
  ~MTX_FLAGMASK);
  431 if (TD_IS_RUNNING(owner)) {
  432 if (LOCK_LOG_TEST(m-lock_object, 
  0))
  433 CTR3(KTR_LOCK,
  434 %s: spinning on %p 
  held by %p,
  435 __func__, m, owner);
  (kgdb)
 
  I'm told that MTX_CONTESTED was set on the unlocked mtx and that 
  MTX_CONTENDED
  is spuriously left behind, and to ask how lock prefix is handled in bhyve. 
  Any
  of that make sense to anyone?
 
 The mutex has both MTX_CONTESTED and MTX_UNOWNED set on it?  That is a
 special sentinel value that is set on a mutex when it is destroyed
 (see MTX_DESTROYED in sys/mutex.h).  If that is the case it looks like
 you've stumbled upon some kind of use-after-free in tmpfs.  I doubt
 that bhyve is responsible (other than perhaps changing the timing
 around making the panic more likely to happen).

Given the first thing seen was:

Freed UMA keg (TMPFS node) was not empty (16 items).  Lost 1 pages of memory.

this sounds reasonable to me.

What can I do to help find and elliminate the source of the error?

Steve


pgplhoUB1IcIi.pgp
Description: PGP signature

Re: tmpfs panic

[Steve Wills]

On Sun, Jul 06, 2014 at 01:49:04PM -0700, Neel Natu wrote:
 Hi Steve,
 
 On Sun, Jul 6, 2014 at 8:46 AM, Steve Wills swi...@freebsd.org wrote:
  I should have noted this system is running in bhyve. Also I'm told this 
  panic
  may be related to the fact that the system is running in bhyve.
 
  Looking at it a little more closely:
 
  (kgdb) list *__mtx_lock_sleep+0xb1
  0x809638d1 is in __mtx_lock_sleep 
  (/usr/src/sys/kern/kern_mutex.c:431).
  426  * owner stops running or the state of the lock 
  changes.
  427  */
  428 v = m-mtx_lock;
  429 if (v != MTX_UNOWNED) {
  430 owner = (struct thread *)(v  
  ~MTX_FLAGMASK);
  431 if (TD_IS_RUNNING(owner)) {
  432 if (LOCK_LOG_TEST(m-lock_object, 
  0))
  433 CTR3(KTR_LOCK,
  434 %s: spinning on %p 
  held by %p,
  435 __func__, m, owner);
  (kgdb)
 
  I'm told that MTX_CONTESTED was set on the unlocked mtx and that 
  MTX_CONTENDED
  is spuriously left behind, and to ask how lock prefix is handled in bhyve. 
  Any
  of that make sense to anyone?
 
 
 Regarding the lock prefix: since bhyve only supports hardware that has
 nested paging, the hypervisor doesn't get in the way of instructions
 that access memory. This includes instructions with lock prefixes or
 any other prefixes for that matter. If there is a VM exit due to a
 nested page fault then the faulting instruction is restarted after
 resolving the fault.
 
 Having said that, there are more plausible explanations that might
 implicate bhyve: incorrect translations in the nested page tables,
 stale translations in the TLB etc.
 
 Do you have a core file for the panic? It would be very useful to
 debug this further.

No, unfortunately I did not have swap or dumpdev setup at the time so I was
unable to get a core dump from the crashed kernel. (Bhyve did not crash.) I've
setup swap in the VM and set the dumpdev as well, so if it happens again I
should get a core.

Steve


pgpSqWLqygcAy.pgp
Description: PGP signature

Re: login.conf -- UTF-8

[Steve Wills]

On Wed, Apr 02, 2014 at 03:56:35PM -0700, Sean Bruno wrote:
 On Wed, 2014-04-02 at 18:06 -0400, Garrett Wollman wrote:
  In article 1396457629.2280.2.ca...@powernoodle.corp.yahoo.com,
  sbr...@freebsd.org writes:
  
  I'd like to make this change to login.conf for default installs.
  
  This removes some amount of hackery in the ports system that is working
  around our lack of UTF-8 in the base.
  
  I'm not sure what the connection is here.  Surely the ports system
  runs with the locale of the user running make (which in my case is
  going to be C).  Any port that requires a specific locale to build
  properly needs to be setting that locale explicitly.
  

You'd think so, but that's not what's happening. What's happening is the
software builds as long as the locale isn't C. Hence, ugly hacks like this:

http://svnweb.freebsd.org/ports/head/Mk/bsd.ruby.mk?annotate=348863#l257

Why? Because the people writing it have never encountered a system where LANG
isn't set or is set to C. Yes, it's a bug in their software. No, they never
have and never will encounter it. Because every other operating system sets
LANG to whatever the user specifies. And so they have no interest in fixing it,
because neither they nor any one they know will ever encounter it, and even if
you report it to them they will tell you it's a bug in your system for not
having LANG specified. And I have no interest in patching it hundreds of
times.

And this is just one example. There are others, I think, that aren't ruby
related at all.

  
 
 I have been informed by folks that this change I suggest would help in
 the case of ports having to declare UTF-8 support explicitly or
 something. I'm hand-wavy on the details and ignorant of the hacks in
 place.  I only know that I've been *told* this.

I think we should join the club of asking the user, but that's more work and
until then having a reasonable default and having people change it seems sane.

Steve
___
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: login.conf -- UTF-8

[Steve Wills]

On Wed, Apr 02, 2014 at 09:31:08PM -0400, Daniel Eischen wrote:
 On Thu, 3 Apr 2014, Steve Wills wrote:
 
  On Wed, Apr 02, 2014 at 03:56:35PM -0700, Sean Bruno wrote:
  On Wed, 2014-04-02 at 18:06 -0400, Garrett Wollman wrote:
  In article 1396457629.2280.2.ca...@powernoodle.corp.yahoo.com,
  sbr...@freebsd.org writes:
 
  I'd like to make this change to login.conf for default installs.
 
  This removes some amount of hackery in the ports system that is working
  around our lack of UTF-8 in the base.
 
  I'm not sure what the connection is here.  Surely the ports system
  runs with the locale of the user running make (which in my case is
  going to be C).  Any port that requires a specific locale to build
  properly needs to be setting that locale explicitly.
 
 
  You'd think so, but that's not what's happening. What's happening is the
  software builds as long as the locale isn't C. Hence, ugly hacks like this:
 
  http://svnweb.freebsd.org/ports/head/Mk/bsd.ruby.mk?annotate=348863#l257
 
  Why? Because the people writing it have never encountered a system where 
  LANG
  isn't set or is set to C. Yes, it's a bug in their software. No, they never
  have and never will encounter it. Because every other operating system sets
  LANG to whatever the user specifies. And so they have no interest in fixing 
  it,
  because neither they nor any one they know will ever encounter it, and even 
  if
  you report it to them they will tell you it's a bug in your system for not
  having LANG specified. And I have no interest in patching it hundreds of
  times.
 
  And this is just one example. There are others, I think, that aren't ruby
  related at all.
 
 The first thing I do when I get a Linux system is set LANG to C.
 I hate all the colorizations and incorrect ordering from ls when
 LANG isn't C.  So you are saying, that ports will be broken when
 I set LANG back to C again?
 
  I have been informed by folks that this change I suggest would help in
  the case of ports having to declare UTF-8 support explicitly or
  something. I'm hand-wavy on the details and ignorant of the hacks in
  place.  I only know that I've been *told* this.
 
  I think we should join the club of asking the user, but that's more work and
  until then having a reasonable default and having people change it seems 
  sane.
 
 A default is fine, but saying that ports will be broken when not
 using the default is not fine.  This is LANG, not a gcc/clang
 machine-specific optimization that someone has set to get an
 extra 0.001% improvement, but happens to break the compiler for
 some ports.

I suppose you're right. Ugly hacks to work around ugly hacks will stay. :)

(Not that I'd planned to remove them any time soon anyway, because such a
change would take a long time to propogate to all supported versions anyway.)

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

11-CURRENT r260369 panic in free_unr

[Steve Wills]

Hi,

I had a panic on a box running r260369. I unfortunately didn't get a core dump,
but did take a picture, available here:

http://meatwad.mouf.net/~swills/panic_r260369_1.jpg

and the backtrace, here:

http://meatwad.mouf.net/~swills/panic_r260369_2.jpg

The box was very heavily loaded doing ports building at the time. Any ideas or
is this perhaps a local hardware issue?

Thanks,
Steve

___
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] removing the NDISulator

[Steve Wills]

I would love to have a native driver for this:

none2@pci0:2:0:0:   class=0x028000 card=0x00101028 chip=0x472714e4 rev=0x01 
hdr=0x00
vendor = 'Broadcom Corporation'
device = 'BCM4313 802.11b/g/n Wireless LAN Controller'
class  = network

Are there docs or other drivers available that we could look at?

Steve

On Fri, Oct 18, 2013 at 11:00:20AM -0700, Adrian Chadd wrote:
 Hi all,
 
 I'd like to remove the NDISulator. I've had many requests to update it to
 the latest NDIS version and support more of the 64 bit wifi drivers. But,
 to be perfectly honest, I have no desire to keep hacking at this. The world
 has changed quite a bit - we can port/reimplement drivers from Linux and
 other BSDs.
 
 So I plan on deorbiting it - I'll mark it deprecated during 11-HEAD and
 target to have it removed by 11.0-RELEASE.
 
 I'd rather see more of an effort writing new drivers and porting drivers
 from other operating systems.
 
 Thanks,
 
 
 
 -adrian
 ___
 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
___
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: Fwd: svn commit: r256256 - in head: . etc etc/defaults etc/rc.d share/man/man5 usr.sbin/jail

[Steve Wills]

I'm having the same issue.

Steve

On Fri, Oct 11, 2013 at 03:05:51PM +0200, Remko Lodder wrote:
 
 Dear Current readers,
 
 Please find issues that I have with the latest /etc/rc.d/jail changes and the 
 use of ezjail.
 
 Thanks
 remko
 
 
 Begin forwarded message:
 
  From: Remko Lodder re...@freebsd.org
  Subject: Re: svn commit: r256256 - in head: . etc etc/defaults etc/rc.d 
  share/man/man5 usr.sbin/jail
  Date: October 11, 2013 3:04:12 PM GMT+02:00
  To: Hiroki Sato h...@freebsd.org
  Cc: src-committ...@freebsd.org, svn-src-...@freebsd.org, 
  svn-src-h...@freebsd.org
  
  
  Hi Hiroki,
  
  On Oct 10, 2013, at 11:32 AM, Hiroki Sato h...@freebsd.org wrote:
  
  Author: hrs
  Date: Thu Oct 10 09:32:27 2013
  New Revision: 256256
  URL: http://svnweb.freebsd.org/changeset/base/256256
  
  Log:
  - Update rc.d/jail to use a jail(8) configuration file instead of
command line options.  The jail_jname_* rc.conf(5) variables for
per-jail configuration are automatically converted to
/var/run/jail.jname.conf before the jail(8) utility is invoked.
This is transparently backward compatible.
  
  - Fix a minor bug in jail(8) which prevented it from returning false
when jail -r failed.
  
  
  Thanks for doing such a massive update. However it seems to break the 
  ezjail utility.
  My jails didn't restart after I upgraded to the most recent -head version 
  
  FreeBSD nakur.elvandar.org 10.0-ALPHA6 FreeBSD 10.0-ALPHA6 #7 r256311: Fri 
  Oct 11 13:27:54 CEST 2013 
  r...@nakur.elvandar.org:/usr/obj/usr/src/sys/NAKUR  amd64
  
  If I replace this with an older version, the utility starts and complains 
  about certain things not being done properly. The
  system does not mount devfs nodes anylonger and thus is basically out of 
  function.
  
  I was not expecting this much fallout from this change, others that will be 
  upgrading will loose the ability to start their jails until they can
  resolve this by hand.
  
  Thanks
  Remko
  
  Approved by:   re (glebius)
  
  Modified:
  head/UPDATING
  head/etc/defaults/rc.conf
  head/etc/rc.d/jail
  head/etc/rc.subr
  head/share/man/man5/rc.conf.5
  head/usr.sbin/jail/jail.c
  
  Modified: head/UPDATING
  ==
  --- head/UPDATING  Thu Oct 10 07:41:11 2013(r256255)
  +++ head/UPDATING  Thu Oct 10 09:32:27 2013(r256256)
  @@ -31,6 +31,25 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 10
 disable the most expensive debugging functionality run
 ln -s 'abort:false,junk:false' /etc/malloc.conf.)
  
  +20131010:
  +  The rc.d/jail script has been updated to support jail(8)
  +  configuration file.  The jail_jname_* rc.conf(5) variables
  +  for per-jail configuration are automatically converted to
  +  /var/run/jail.jname.conf before the jail(8) utility is invoked.
  +  This is transparently backward compatible.  See below about some
  +  incompatibilities and rc.conf(5) manual page for more details.
  +
  +  These variables are now deprecated in favor of jail(8) configuration
  +  file.  One can use rc.d/jail config jname command to generate
  +  a jail(8) configuration file in /var/run/jail.jname.conf without
  +  running the jail(8) utility.   The default pathname of the
  +  configuration file is /etc/jail.conf and can be specified by
  +  using $jail_conf or $jail_jname_conf variables.
  +
  +  Please note that jail_devfs_ruleset accepts an integer at
  +  this moment.  Please consider to rewrite the ruleset name
  +  with an integer.
  +
  20130930:
  
 
 -- 
 /\   With kind regards,  | re...@elvandar.org
 \ /   Remko Lodder| re...@freebsd.org
 XFreeBSD  | http://www.evilcoder.org
 / \   The Power to Serve  | Quis custodiet ipsos custodes
 


___
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: Kernel hang r247079 mps/vfs/zfs?

[Steve Wills]

Hi,

 I was testing a patch on r246300 or so, and wanted to see if it would
 apply
 cleanly to a newer copy of HEAD.

 Well it did, except I had a hang at boot, shortly after ZFS version and
 the
 last scsi devices appear.
 This easily could have been related to the patch I was testing, so I wiped
 /usr/src/ and /usr/obj (after booting kernel.old) and rebuilt world and
 kernel cleanly.

 I assumed that would resolve the issue, but it did not.

 The hang happens right after zfs is announced, and the last da devices
 (some of which are usb) are reported. It comes before the noisy output of
 mps.

 Hang is complete, and single user or verbose don't yield much.

 I'm having trouble exfiltrating a dmesg from it, but it may be unrelated
 to
 the userland issues reported earlier, as single user does not resolve it
 for me.
 The svn up was at 11:20 pacific (GMT +8).

 Anyone else seeing similar issues?

 Hardware is an LSI mps device, 9210 crossflashed m1015. Pool is a zfs
 mirror. Works fine booting from r246300 kernel.
 Motherboard is an AMD Tyan.
 Pulling USB headers off the board didn't resolve it.

I am experiencing a similar hang when updating from r246190 to r247017 on
my all zfs system. The system has two drives in a zfs mirror and hangs
after detecting the hard drives. The last thing seen is the ada1:
Previously was known as ad8 message, then it hangs completely, unable to
even ctrl-alt-del or even get the numlock key to toggle the light. System
is:

CPU: AMD Phenom(tm) II X4 955 Processor (3214.39-MHz K8-class CPU)

with ASUS M4A78LT-M board. Let me know if other details will help.

Steve


___
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: -Current built with clang as default + ports

[Steve Wills]

On 11/13/12 18:51, AN wrote:
 Can anyone comment on current built with clang as default compiler and
 ports?  Are there any major problems, programs that don't run? 
 Specifically, I am interested in how Gnome and Xorg (Gnome and Xorg
 built with default system gcc) work on world built with clang.

I can't comment on Gnome, but I run current on my desktop and use KDE4.
I had to patch a few ports to build. Those patches have been sent in as PRs.

Overall, the switch to ports built with clang was amazingly uneventful.
So far, I haven't noticed anything that built but didn't work properly.

 I believe the work around for ports that don't build with clang is to
 put USE_GCC=4.7+ in the port makefile, is this correct?  Any comments
 would be appreciated, thanks in advance.

A good bit of fixing for clang has already been done. I was able to fix
pretty much everything I encountered that didn't build with clang, so
didn't have to set USE_GCC anywhere, but it's there as a last resort.

Of course, those are just my experiences, YMMV.

Steve

___
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

current sluggish under load in the last few weeks

[Steve Wills]

Hi All,

Has something changed in the scheduler recently? I don't have anything
concrete, just anecdotal evidence, but my current desktop feels a little
less responsive under heavy CPU load than it did a few weeks ago.
Usually my high CPU processes (builds) are nice'd, but even with that,
thing still get kinda sluggish, for example the mouse pointer will take
it's time responding. Didn't do that a few weeks back. Wondering if it's
just me?

Thanks,
Steve
___
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

panic with racct

[Steve Wills]

Hi,

I get this panic:

Fatal trap 18: integer divide fault while in kernel mode
cpuid = 4; apic id = 04
instruction pointer = 0x20:0x808f0c23
stack pointer   = 0x28:0xff83693b8b40
frame pointer   = 0x28:0xff83693b8ba0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 21 (racctd)

with these options added to my kernel:

options RCTL
options RACCT

This is with r242578. Removing them avoids the issue. The relevant code
seems to be:

% addr2line -e /boot/kernel.old/kernel 0x808f0c23
/usr/src/sys/kern/kern_racct.c:1142

Let me know if more info is needed, or if I should file a PR.

Thanks,
Steve
___
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

pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap

[Steve Wills]

Hi,

It seems to me that renaming the pkg binary in /usr/sbin/pkg to 
/usr/sbin/pkg-bootstrap would make sense. From a user standpoint, it is 
confusing that running the command gets different results the second time it is 
run vs. the first time. I can imagine a user saying I ran pkg, but it didn't 
do what they said it would.  Now I run it again, and it does do what it is 
supposed to. Also, it would enable setting up a pkg-bootstrap man page 
separate from the pkg man page, without confusion about which one you're 
looking at.

So, opinions? There may still be time to fix it for 9.1 if we can decide 
quickly.

Thanks,
Steve

___
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: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap

[Steve Wills]

On Aug 23, 2012, at 9:57 PM, Eitan Adler wrote:

 On 23 August 2012 18:19, Steve Wills swi...@freebsd.org wrote:
 Hi,
 
 It seems to me that renaming the pkg binary in /usr/sbin/pkg to 
 /usr/sbin/pkg-bootstrap would make sense. From a user standpoint, it is 
 confusing that running the command gets different results the second time it 
 is run vs. the first time. I can imagine a user saying I ran pkg, but it 
 didn't do what they said it would.  Now I run it again, and it does do what 
 it is supposed to. Also, it would enable setting up a pkg-bootstrap man 
 page separate from the pkg man page, without confusion about which one 
 you're looking at.
 
 So, opinions? There may still be time to fix it for 9.1 if we can decide 
 quickly.
 
 no opinion on the name, but imho there should be *something* called
 pkg on a fresh system. Users will install a new system, follow some
 random how-to, and not realize they missed a step. If the default
 package errors with exit code 1 and says run pkgbootstrap first that
 is okay too.

Why can't one of those steps be to run pkg-bootstrap?

Steve

___
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: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap

[Steve Wills]

On Aug 23, 2012, at 10:08 PM, Eitan Adler wrote:

 On 23 August 2012 22:05, Steve Wills swi...@freebsd.org wrote:
 
 Why can't one of those steps be to run pkg-bootstrap?
 
 Because the how-to may not be for a new system ;)

The possibility of bad docs somewhere outside of our control, when we can (and 
I am actively working on) document(ing) pkgng for the handbook seems kinda 
thin. It's not even Something's wrong on the Internet! 
(http://xkcd.com/386/), it's Something might some day be wrong on the 
Internet!

Steve

___
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: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap

[Steve Wills]

On Aug 23, 2012, at 10:23 PM, Eitan Adler wrote:

 On 23 August 2012 22:15, Steve Wills swi...@freebsd.org wrote:
 On Aug 23, 2012, at 10:08 PM, Eitan Adler wrote:
 
 On 23 August 2012 22:05, Steve Wills swi...@freebsd.org wrote:
 
 Why can't one of those steps be to run pkg-bootstrap?
 
 Because the how-to may not be for a new system ;)
 
 The possibility of bad docs somewhere outside of our control, when we can 
 (and I am actively working on) document(ing) pkgng for the handbook seems 
 kinda thin. It's not even Something's wrong on the Internet! 
 (http://xkcd.com/386/), it's Something might some day be wrong on the 
 Internet!
 
 It isn't a problem of bad docs. Its a problem of the user following
 some not-for-new-systems documentation and getting very confused when
 they see command not found.. It is practically the definition of
 POLA.

As far as I understand it, POLA is about changing existing things:

http://www.freebsd.org/doc/handbook/freebsd-glossary.html#POLA-GLOSSARY

So this isn't POLA, it's documentation.

Steve

___
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 create a FreeBSD 10.0-CURRENT/amd64 media? Where are the ISOs?

[Steve Wills]

On 08/16/12 17:13, O. Hartmann wrote:
 Am 08/16/12 22:58, schrieb Warren Block:
 On Thu, 16 Aug 2012, O. Hartmann wrote:

 I find myself a bit floating when I looked for snapshot images for
 DVD/CD for rescue discs for FreeBSD 10.0-CURRENT/amd64. I can not find
 anything following the webpage www.freebsd.org! Most links with
 snapshot or places like ISO-Images-X refere to some places with
 year-2011 folders. Am I blind?

 https://pub.allbsd.org/FreeBSD-snapshots/
 

Those are very helpful, I've found them very handy myself on several
occasion. If you want to make your own, you can do so by first building
world/kernel then:

cd /usr/src/release
make clean
make release

I believe nwhitehorn@ sent a mail with more detail about this to this
list when when he made the changes, but it was a while ago, I could be
misremembering.

Steve
___
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 create a FreeBSD 10.0-CURRENT/amd64 media? Where are the ISOs?

[Steve Wills]

On 08/16/12 17:44, Steve Wills wrote:
 On 08/16/12 17:13, O. Hartmann wrote:
 Am 08/16/12 22:58, schrieb Warren Block:
 On Thu, 16 Aug 2012, O. Hartmann wrote:

 I find myself a bit floating when I looked for snapshot images for
 DVD/CD for rescue discs for FreeBSD 10.0-CURRENT/amd64. I can not find
 anything following the webpage www.freebsd.org! Most links with
 snapshot or places like ISO-Images-X refere to some places with
 year-2011 folders. Am I blind?

 https://pub.allbsd.org/FreeBSD-snapshots/

 
 Those are very helpful, I've found them very handy myself on several
 occasion. If you want to make your own, you can do so by first building
 world/kernel then:
 
 cd /usr/src/release
 make clean
 make release
 
 I believe nwhitehorn@ sent a mail with more detail about this to this
 list when when he made the changes, but it was a while ago, I could be
 misremembering.
 

Sorry for the double mail. Here's the message I was thinking of:

http://lists.freebsd.org/pipermail/freebsd-current/2011-March/023465.html

Steve

___
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: zfsloader failure with r239244

[Steve Wills]

On 08/14/12 15:42, Andrey V. Elsukov wrote:
 On 14.08.2012 21:03, Steve Wills wrote:
 Any ideas if this is a bug or something wrong with my system would be
 appreciated.
 
 Can you boot with serial console and show what show the `lsdev` command
 in the loader?
 And from the running system the output of `gpart show` and
 `zpool status`.
 

For the record, this was fixed by r239293 and r239294.

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

zfsloader failure with r239244

[Steve Wills]

Hi,

I just upgraded my system from r238261 to r239244 and was unable to boot
one of my zfs root systems. I had to recover using the zfsloader.old
that is kept in /boot. The messages from zfsloader were:

ZFS: can't find pool by guid
ZFS: can't find pool by guid

can't load 'kernel'

followed by a loader prompt. My loader.conf has:

vfs.root.mountfrom=zfs:zroot

as well as other settings.

I suspect this may be related to the fact that my zfs root is formatted
using a legacy on-disk format. Specifically, it is version 14 and for
the record it's on an MBR partition. This system also has two other
pools, one which is version 28 and another which is the latest zpool
version (I think? No version number is shown in zpool list -o all,
only a -). I've avoided zpool upgrading this pool because I'm a little
nervous about updating zfsboot via dd.

I didn't see the issue on another zfs root system which is using GPT and
the latest zpool version and was upgraded from/to the same versions.

Any ideas if this is a bug or something wrong with my system would be
appreciated.

Thanks,
Steve
___
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: panic after starting X with r238120

[Steve Wills]

On 07/08/12 13:56, Alan Cox wrote:
 
 
 In r237513 on 6/23 I made a mistake that was corrected in r238124 on 7/5.
 I can vaguely see a connection between kern.ipc.shm_use_phys and the
 problem fixed in r238124.  So, I'd like to know if this problem still
 exists.  Wait, however, until you see Kostik commit a change to
 vm_pageout.c, before you update your system.
 
 

I booted r238261 with kern.ipc.shm_use_phys=1 and the problem seems to
have disappeared. Thanks!

Steve
___
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: panic after starting X with r238120

[Steve Wills]

Following up to myself, with some things I should have mentioned before:

On 07/05/12 19:59, Steve Wills wrote:
 On 07/05/12 03:00, Alan Cox wrote:
 On Wed, Jul 4, 2012 at 4:57 PM, Steve Wills swi...@freebsd.org wrote:

 Setting kern.ipc.shm_use_phys back to 0 (the default) fixed it. I had set
 it to 1 for some reason that I can't recall.


 That shouldn't cause a crash in pmap_enter().  What is line 3587 of pmap.c
 in your sources? 
 
 3587 if ((newpte  PG_RW) == 0)
 
 You mentioned DRM.  Are you using the new Intel graphics
 driver?

 
 No, I'm using ATI Radeon.
 

For what it's worth, I discovered that twm and xterm don't trigger the
issue, but konsole and other kde things do, which is what led me to
discover that setting kern.ipc.shm_use_phys back to default fixed it.

This wasn't the case before, I think the last time I updated was about a
month ago, May 6.

Also, I have these other shared memory related settings in sysctl.conf:

kern.ipc.shmmax=67108864
kern.ipc.shmall=32768
kern.ipc.shm_allow_removed=1

I'm wondering if this is an indication that I have/had some bad settings
and they finally bit me, or if this is an indication of a bug.

Thanks,
Steve
___
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: panic after starting X with r238120

[Steve Wills]

On 07/05/12 03:00, Alan Cox wrote:
 On Wed, Jul 4, 2012 at 4:57 PM, Steve Wills swi...@freebsd.org wrote:
 
 Setting kern.ipc.shm_use_phys back to 0 (the default) fixed it. I had set
 it to 1 for some reason that I can't recall.


 That shouldn't cause a crash in pmap_enter().  What is line 3587 of pmap.c
 in your sources? 

3587 if ((newpte  PG_RW) == 0)

 You mentioned DRM.  Are you using the new Intel graphics
 driver?
 

No, I'm using ATI Radeon.

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

panic after starting X with r238120

[Steve Wills]

Hi,

After updating to r238120, I get a panic whenever X starts up. It works for a 
few seconds, then panics. The messages don't look too useful to me, but here 
they are:

Unread portion of the kernel message buffer:
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 3610 (kdm_greet)
trap number = 12
panic: page fault
cpuid = 0

(kgdb) bt
#0  doadump (textdump=dwarf2_read_address: Corrupted DWARF expression.
) at pcpu.h:224
#1  0x8087ef79 in kern_reboot (howto=dwarf2_read_address: Corrupted 
DWARF expression.
) at kern_shutdown.c:449
#2  0x8087f413 in panic (fmt=dwarf2_read_address: Corrupted DWARF 
expression.
) at kern_shutdown.c:637
#3  0x80b77d08 in trap_fatal (frame=dwarf2_read_address: Corrupted 
DWARF expression.
) at trap.c:852
#4  0x80b78012 in trap_pfault (frame=dwarf2_read_address: Corrupted 
DWARF expression.
) at trap.c:678
#5  0x80b777aa in trap (frame=Variable frame is not available.
) at trap.c:456
#6  0x80b62142 in calltrap () at /tmp/exception-vH8hmc.s:179
#7  0x80b6f6b0 in pmap_enter (pmap=dwarf2_read_address: Corrupted DWARF 
expression.
) at pmap.c:3587
#8  0x80adafa0 in vm_fault_hold (map=dwarf2_read_address: Corrupted 
DWARF expression.
) at vm_fault.c:935
#9  0x80ad9787 in vm_fault (map=Variable map is not available.
) at vm_fault.c:229
#10 0x80b77f26 in trap_pfault (frame=dwarf2_read_address: Corrupted 
DWARF expression.
) at trap.c:736
#11 0x80b77670 in trap (frame=Variable frame is not available.
) at trap.c:358
#12 0x80b62142 in calltrap () at /tmp/exception-vH8hmc.s:179
#13 0x0008040d7796 in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language:  auto; currently minimal
(kgdb) 

Something I saw in a previous panic made me think this was drm related, but I 
don't see it in this particular one.

Steve

___
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: panic after starting X with r238120

[Steve Wills]

Setting kern.ipc.shm_use_phys back to 0 (the default) fixed it. I had set it to 
1 for some reason that I can't recall.

Steve

On Jul 4, 2012, at 5:41 PM, Steve Wills wrote:

 Hi,
 
 After updating to r238120, I get a panic whenever X starts up. It works for a 
 few seconds, then panics. The messages don't look too useful to me, but here 
 they are:
 
 Unread portion of the kernel message buffer:
 processor eflags= interrupt enabled, resume, IOPL = 0
 current process = 3610 (kdm_greet)
 trap number = 12
 panic: page fault
 cpuid = 0
 
 (kgdb) bt
 #0  doadump (textdump=dwarf2_read_address: Corrupted DWARF expression.
 ) at pcpu.h:224
 #1  0x8087ef79 in kern_reboot (howto=dwarf2_read_address: Corrupted 
 DWARF expression.
 ) at kern_shutdown.c:449
 #2  0x8087f413 in panic (fmt=dwarf2_read_address: Corrupted DWARF 
 expression.
 ) at kern_shutdown.c:637
 #3  0x80b77d08 in trap_fatal (frame=dwarf2_read_address: Corrupted 
 DWARF expression.
 ) at trap.c:852
 #4  0x80b78012 in trap_pfault (frame=dwarf2_read_address: Corrupted 
 DWARF expression.
 ) at trap.c:678
 #5  0x80b777aa in trap (frame=Variable frame is not available.
 ) at trap.c:456
 #6  0x80b62142 in calltrap () at /tmp/exception-vH8hmc.s:179
 #7  0x80b6f6b0 in pmap_enter (pmap=dwarf2_read_address: Corrupted 
 DWARF expression.
 ) at pmap.c:3587
 #8  0x80adafa0 in vm_fault_hold (map=dwarf2_read_address: Corrupted 
 DWARF expression.
 ) at vm_fault.c:935
 #9  0x80ad9787 in vm_fault (map=Variable map is not available.
 ) at vm_fault.c:229
 #10 0x80b77f26 in trap_pfault (frame=dwarf2_read_address: Corrupted 
 DWARF expression.
 ) at trap.c:736
 #11 0x80b77670 in trap (frame=Variable frame is not available.
 ) at trap.c:358
 #12 0x80b62142 in calltrap () at /tmp/exception-vH8hmc.s:179
 #13 0x0008040d7796 in ?? ()
 Previous frame inner to this frame (corrupt stack?)
 Current language:  auto; currently minimal
 (kgdb) 
 
 Something I saw in a previous panic made me think this was drm related, but I 
 don't see it in this particular one.
 
 Steve
 
 ___
 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

___
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: panic's in 10-CURRENT r235646 in VMware

[Steve Wills]

Hi Matthais,

On 06/27/12 01:19, Matthias Apitz wrote:
 El día Saturday, June 16, 2012 a las 08:11:40AM -0400, John Baldwin escribió:
 
 On Saturday, June 16, 2012 04:51:06 AM Matthias Apitz wrote:
 El día Friday, June 15, 2012 a las 08:18:22AM -0400, John Baldwin escribió:
 the panic says:
 mutex page lock not owned at /usr/src/sys/vm/vm_page.c:2060

 I have a screen shoot here:
 http://www.unixarea.de/aurora-panic.gif

 Installed and started (via rc.conf) is the port open-vm-tools-425873,1;

 Thx

   matthias

 Can you get a stack trace?
 
 The attached patch file (to be replaced in 
 open-vm-tools/files/patch-vmmemctl-os.c)
 solved the problem for me; thanks, John
 
   matthias
 

Thanks! I've updated the port with this and the other patches you sent
and it seems to build and work properly on 10-CURRENT.

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

panic with out of memory

[Steve Wills]

Hi,

I just got a panic out of my r237195 system. The panic looks like:

Sleeping thread (tid 173153, pid 42034) owns a non-sleepable lock
KDB: stack backtrace of thread 173153:
sched_switch() at sched_switch+0x28a
mi_switch() at mi_switch+0xdf
sleepq_timedwait() at sleepq_timedwait+0x3a
_sleep() at _sleep+0x266
swp_pager_meta_build() at swp_pager_meta_build+0x259
swap_pager_copy() at swap_pager_copy+0x17b
vm_object_collapse() at vm_object_collapse+0x123
vm_object_deallocate() at vm_object_deallocate+0x457
vm_map_process_deferred() at vm_map_process_deferred+0x72
vm_pageout_oom() at vm_pageout_oom+0x180
swp_pager_meta_build() at swp_pager_meta_build+0x248
swap_pager_copy() at swap_pager_copy+0x17b
vm_object_collapse() at vm_object_collapse+0x123
vm_object_deallocate() at vm_object_deallocate+0x457
vm_map_process_deferred() at vm_map_process_deferred+0x72
vm_map_remove() at vm_map_remove+0x116
exec_new_vmspace() at exec_new_vmspace+0x1bc
exec_elf64_imgact() at exec_elf64_imgact+0x5f4
kern_execve() at kern_execve+0x6f0
sys_execve() at sys_execve+0x37
amd64_syscall() at amd64_syscall+0x351
Xfast_syscall() at Xfast_syscall+0xfb
--- syscall (59, FreeBSD ELF64, sys_execve), rip = 0x800d2eddc, rsp =
0x7fffd328, rbp = 0x7fffd470 ---
panic: sleeping thread
cpuid = 4

The system was very busy and using lots of swap, but I didn't expect a
panic. If any more detail is needed or I should just get more RAM, let
me know. :)

Thanks,
Steve
___
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: jemalloc: jemalloc_arena.c:182: Failed assertion: p[i] == 0

[Steve Wills]

On 05/08/12 00:46, Jason Evans wrote:
 
 How recent is your system?  This problem should have been fixed by
 r234569, so if you're still seeing problems after that revision,
 there's another problem we need to figure out.  (By the way, it's
 possible for an application to trigger this assertion, but
 unlikely.)
 

My system is r235115.

Steve
___
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: ctfmerge core dump

[Steve Wills]

 On 2012/5/6 5:08, b. f. wrote:
 On 5/5/12, Steve Willsswi...@freebsd.org  wrote:
 Thanks for the info. I took a look at the dump and see this:

 % sudo gdb /usr/bin/ctfmerge ctfmerge.core
 [GDB will not be able to debug user-mode threads: Undefined symbol
 td_thr_getxmmregs]

 Hmm, is the thread debugging broken on amd64 now ?  td_thr_getxmmregs
 resides
 in libthread_db and /usr/src/gnu/usr.bin/gdb/libgdb is complaining about
 the missing
 symbol.


Maybe or maybe I have done something wrong on my system. FWIW, I do all my
builds with debugging enabled.

BTW, just to confirm, I was able to work around the original issue once I
updated past r235068. I had to disable DTrace build and build and install
a new libthr, then was able to re-enable DTrace and everything was fine.

Thanks,
Steve


___
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: jemalloc: jemalloc_arena.c:182: Failed assertion: p[i] == 0

[Steve Wills]

 On Apr 21, 2012, at 11:54 AM, David Wolfskill wrote:
 After applying Dimitry Andric's patches to contrib/jemalloc and
 replacing
 /usr/bin/as with one built last Sunday, I was finally(!) able to rebuild
 head as of 234536:

 FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #797
 234536M: Sat Apr 21 10:23:33 PDT 2012
 r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC  i386

 However, as I was copying a /usr/obj hierarchy via tar -- e.g.:

 root@freebeast:/common/home/david # (cd /var/tmp  rm -fr obj  mkdir
 obj)  (cd /usr  tar cpf - obj) | (cd /var/tmp  tar xpf -)

 it ran for a while, then:

 jemalloc: jemalloc_arena.c:182: Failed assertion: p[i] == 0
 Abort (core dumped)
 root@freebeast:/common/home/david # echo $?
 134
 root@freebeast:/common/home/david # ls -lTio *.core
 ls: No match.
 root@freebeast:/common/home/david #

 So ... no core file, apparently.

 freebeast(10.0-C)[2] find /usr/src/contrib/jemalloc -type f -name
 jemalloc_arena.c
 freebeast(10.0-C)[3]

 No file named jemalloc_arena.c, either.

 But contrib/jemalloc/src/arena.c contains a function,
 arena_chunk_validate_zeroed():

175 static inline void
176 arena_chunk_validate_zeroed(arena_chunk_t *chunk, size_t run_ind)
177 {
178 size_t i;
179 UNUSED size_t *p = (size_t *)((uintptr_t)chunk + (run_ind
  LG_PAGE));
180
181 for (i = 0; i  PAGE / sizeof(size_t); i++)
182 assert(p[i] == 0);
183 }

 Thoughts?

 I received a similar report yesterday in the context of filezilla, but
 didn't get as far as reproducing it.  I think the problem is in
 chunk_alloc_dss(), which dangerously claims that newly allocated memory is
 zeroed.  It looks like I formalized this bad assumption in early 2010,
 though the bug existed before that.  It's a bigger deal now because sbrk()
 is preferred over mmap(), so the bug has languished for a couple of years.
  I'll get a fix committed today (and revert the order of preference
 between sbrk() and mmap()).

 By the way, I wonder why not everyone hits this (I don't).


I just now hit the same issue while using ports tinderbox. It was calling
tar during the makeJail tinderbox subcommand and gave the same error as
in the subject. Funny thing is I had run the same command (on a different
jail) right before this and didn't get the error. What's the status of
this? Should I set MALLOC_PRODUCTION=yes in /etc/make.conf, rebuild world
and forget about it?

Steve


___
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

ctfmerge core dump

[Steve Wills]

After updating from -CURRENT as of April 5 to one built today, I now get
a core dump running ctfmerge on libc:

ctfmerge -L VERSION -g -o libc.so.7 syscall.So fork.So..
Bus error (core dumped)
*** [libc.so.7] Error code 138

Anyone else seeing this or have any idea how to avoid it? Let me know if
you need more details on my config.

Thanks,
Steve
___
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: ctfmerge core dump

[Steve Wills]

On 05/05/12 15:43, b. f. wrote:
 Steve Wills wrote:
 After updating from -CURRENT as of April 5 to one built today, I now get
 a core dump running ctfmerge on libc:

 ctfmerge -L VERSION -g -o libc.so.7 syscall.So fork.So..
 Bus error (core dumped)
 *** [libc.so.7] Error code 138

 Anyone else seeing this or have any idea how to avoid it?
 
 Yes, I'm also seeing such problems when attempting to build a r235052
 amd64 kernel on r235035 amd64. (This problem did not occur when
 building a r235035 amd64 world and kernel on r234854 amd64.)  ctfmerge
 succeeds for several kernel modules but fails with kgssapi.ko.debug,
 linux.ko.debug, or kernel.debug. I'm not yet sure which change has
 caused this, or how to avoid it.
 

Thanks for the info. I took a look at the dump and see this:

% sudo gdb /usr/bin/ctfmerge ctfmerge.core
[GDB will not be able to debug user-mode threads: Undefined symbol
td_thr_getxmmregs]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...
Core was generated by `ctfmerge'.
Program terminated with signal 10, Bus error.
Reading symbols from /lib/libctf.so.2...done.
Loaded symbols for /lib/libctf.so.2
Reading symbols from /usr/lib/libdwarf.so.3...done.
Loaded symbols for /usr/lib/libdwarf.so.3
Reading symbols from /usr/lib/libelf.so.1...done.
Loaded symbols for /usr/lib/libelf.so.1
Reading symbols from /lib/libz.so.6...done.
Loaded symbols for /lib/libz.so.6
Reading symbols from /lib/libthr.so.3...done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x004064b0 in fifo_len (f=0x801c29070) at
/usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c:128
128 for (i = 0, fn = f-f_head; fn; fn = fn-fn_next, i++);
(gdb) bt
#0  0x004064b0 in fifo_len (f=0x801c29070) at
/usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c:128
#1  0x0040622c in worker_thread (wq=0x610ee0) at
/usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/ctfmerge.c:329
#2  0x000801078da9 in thread_start (curthread=0x801c0f800) at
/usr/src/lib/libthr/thread/thr_create.c:284
#3  0x in ?? ()
Cannot access memory at address 0x7f5fb000
(gdb)

Not sure what to make of that.

Steve

___
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: flowtable usable or not

[Steve Wills]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/29/12 13:17, K. Macy wrote:
 .
 
 I tried it, on both FreeBSD routers, web systems, and database 
 servers; all on 8.2+. It still causes massive instability.
 Disabling the sysctl, and/or removing it from the kernel solved
 the problems.
 
 Routing I can believe, but I'm wondering how close attention you
 paid to the workload. There are CDN networks with high uptimes and
 shipping firewall products that use flowtable, so your mention of
 web systems forces makes me ask for specifics.
 

The failure I experienced was with web servers running 8.0 behind a F5
load balancer in an HA setup. Whenever the failover happened, the web
servers would continue sending to the wrong MAC address, despite the
arp table updating. Disabling flowtable via the sysctl solved the
problem. Maybe Doug's failure was similar, maybe not, but I thought
I'd throw my $0.02 in.

Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBAgAGBQJPTtiJAAoJEPXPYrMgexuhp8EIAKGGtZzcxgQ4zVO5SKy1jAOH
DXLRLYfdm8NJB9hYEvtUa9/nltAE35zQMp7FU4AlZ2L2ol/J7W9aODiN0gw9AFEr
dxBYyQliDKvVwLgah9a5PaXNM3kpx9ZvZGM3lBQGQbZaEV+ERwjBXkfIqjEB4Ei5
bBd7841jQm22s1xJOuJTdMGrpnY1DMUPdPCFOAtyQmTAhWpoELgtQBvP9kGYNKv2
3NAPnjFuooe9fdze9VSO8TWFJSb82DVbRsz6JiR0998oHXPApCh4I5y1rNcg2qA/
1x2EdFlivXpgjC4nKUgFjhohmdGv20FrLfex4eOq6dSMF0Baje86PJcc8EZ1DK0=
=NUft
-END PGP SIGNATURE-
___
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] modular kernel config

[Steve Wills]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/27/12 10:53, Łukasz Wąsikowski wrote:
 W dniu 2012-02-22 23:31, Bjoern A. Zeeb pisze:
 
 You cannot ship that on by default for non-tecnical reasons in a
 kernel.  Please do not commit a kernel config that can be booted
 (no LINT cannot be booted) with these on without consulting
 appropriate hats upfront.
 
 
 - ALTQ - SW_WATCHDOG - QUOTA - IPSTEALTH (disabled in
 loader.conf) - IPFIREWALL_FORWARD (touches every packet, power
 users which need a bigger PPS but not this feature can
 recompile the kernel, discussed with julian@) - FLOWTABLE
 (disabled in loader.conf)
 Which is not the same as it's not 100% disabled and will still
 allocate memory.
 
 FLOWTABLE on 8.x crashed BGP routers (kern/144917). I don't know if
 it is fixed by now, but this kind of potential problematic features
 should not be enabled by default.
 

Agree, I've run into problems with FLOWTABLE (with just the features
that were enabled by default in 8.0) when routers changed MAC
addresses. As far as I understand it, FLOWTABLE is both broken and
abandoned (but if I'm wrong, please let me know).

So, IMHO, not only should it not be enabled by default, but given that
it was disabled complete in 8.x after 8.0 (too lazy to look at exactly
when right now), I think it shouldn't even be included, since that
might encourage users to try it out only to encounter problems with it.

Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBAgAGBQJPTD/nAAoJEPXPYrMgexuhvWAH/iPa0N32GJXdyL7OdqFNNuEN
R/Z0tOqTCCmAm4WsbAbN3m5poBKNctRtQxG40XoqmvZAWlomwYCwpS2xgCX60NZO
XhspUEpQ7cHQpt6ZOW12x3G6FZJ4DzFX0+mDPYxE/7YmwtsjZFeTFGVEPezeKQwr
Khar5jWYqETmM1+mFvAFXnfTUiBwnqErDfYmHQAE93wKQd9CyzrFmDfooNTiMUB6
yW+piexN/SzXz6nftQesJbFOWUW6fvhxe9TYcK8+b9zCo2GxPuUrRV60PKQX0apd
nlKWtj49znLVzmpTYboQnvmqmk+yik8wL2wszUaZ4jAjieCjWOhJwCWOvkQ9yIg=
=SBbK
-END PGP SIGNATURE-
___
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

7.x gcc won't run

[Steve Wills]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Yesterday afternoon, I updated my -CURRENT host. Then I updated the
jails (chroots) that my ports tinderbox uses. Now I've found that the
7.x and 8.x ones can't run gcc as it reports:

gcc: Internal error: Abort trap: 6 (program cc1)

9.x things work fine and other 7.x and 8.x binaries seem to run fine.
Anyone have any ideas?

Thanks,
Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (FreeBSD)

iQEcBAEBAgAGBQJOdWgYAAoJEPXPYrMgexuhDcYH/jImRJ08OFgGzOowHMe/uhoM
2dx1qW/BQprnmv3oRZ7XtOiHNpi18t/rgtzSG+LIojbYdGvVRIyEWaU/tLfGjGGA
HaVAOGtBaLv4RuLRanFdkRDbMS3/GZmZZsDf+UrxTxgihsLRwi7Vx20xa5aVCeOa
OYtRbSLB3xePIiExOjqLtqibCdkcohZe+mucsJjttVPLoxo4Nso0Be125XRJ4RcY
aZ/lwYCbxurGFLcfakKCLvBZzb0TB8pnShMtxDCsm6VsKjO5rMCMCyTsxApMxdWe
E9kcInvkxEfp44panzKrazN6/IXyCTuTmiCktQaBBsDQ8pHOpNPOSiwTz2wfpvM=
=WNAv
-END PGP SIGNATURE-
___
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.x gcc won't run

[Steve Wills]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Please disregard this, it was a local issue that I resolved. I had tried
to enable userland Dtrace (WITH_CTF), but mistakenly did it for 7.x and
8.x as well as 9.x. Sorry for the noise.

Steve

On 09/17/11 23:40, Steve Wills wrote:
 Hi,
 
 Yesterday afternoon, I updated my -CURRENT host. Then I updated the
 jails (chroots) that my ports tinderbox uses. Now I've found that the
 7.x and 8.x ones can't run gcc as it reports:
 
 gcc: Internal error: Abort trap: 6 (program cc1)
 
 9.x things work fine and other 7.x and 8.x binaries seem to run fine.
 Anyone have any ideas?
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (FreeBSD)

iQEcBAEBAgAGBQJOdX82AAoJEPXPYrMgexuhkEAH/j/wd3Xlk1UrGf3i7IWpa6Vb
7+8JG+C4kE4WZzIhqD8QR4dXtzeqHlnc4XObI5wjUgDULHXMdl//E5WiHsKi+WI6
SqpMuy3dkn10WU2jQdB+d2BPldtrFerzKyxU+HXjBZyBv7JH2hJhblmr0HUpinD1
9QBgaL0f46QL/Th7E02Zg2wLx3EI+dk4FsFaRNkTVZOC7/m7DIEQe/fwVQnFU2ci
3S9vf5si3Dc7uIZSDdstCXFLOeZP8aEsc6pXvytpVQEFGYBFDQQzom1U4/ONFz8y
BU/scyvdrH5Lh2FURfmCjH9PiO6p10neu+7KugaegOboR8w9VjSOAaJb4U8M+E0=
=gmLL
-END PGP SIGNATURE-
___
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: NFS mountd version 3 over TCP

[Steve Wills]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/27/11 21:23, Steve Wills wrote:
 On 08/27/11 20:55, Rick Macklem wrote:
 I don't know why the nfsd wouldn't be able to bind(2) to port #2049 a
 second time for UDP, but someone on the net side might know? (Just in
 case it is a problem that has already been fixed, I'd try a newer kernel.)
 
 Will do, see below.
 
 The new server was broken by r224778 on Aug. 11 and fixed by r224911 on
 Aug. 16. (I recall you mentioning Aug. 11?)
 
 My kernel is from Aug 13, so definitely would fall into that range. I'll
 update and rebuild and see how it goes.
 

After working around the /dev/stdout issue by booting an old kernel and
doing a buildworld from there, I was able to update my kernel to todays
sources. ESXi is now able to mount the nfs share. However, when I
attempt to start a VM, it reports:

Failed to power on VM.
Unable to retrieve the current working directory: 0 (Input/output
error). Check if the directory has been deleted or unmounted.

and

FILE: File_Cwd: getcwd() failed: Input/output error

I have tcpdump output available here:

http://people.freebsd.org/~swills/nfs2.pcap

if that helps.

Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (FreeBSD)

iQEcBAEBAgAGBQJOWzShAAoJEPXPYrMgexuhxo0H/0ALErvMrpcxtkuUv07ipj0O
Z8p3YkMFkckSy6s0QCAOCVgjbqZptCkKg96vMehG3nI5o2HtA43h5y6UNvMi1FWE
WOiIFbzXkgfn1pubv2YyFwaDK1aFXMswwYaCHSP7a+K8fpjDOiR5ZnhhyXcb7k1X
YmURkSEbLbngLdIfywPATSiby9PyFVqyMjhU3yW/Y8QLueEjK4xq5RsbmU1Qmv2B
bjA11x9birNvc//iBp6zTqBP752soqK+M9aXrjjm9GzhN0UeKdXseWt9zd3mu2qs
cfPUqz7DSATQNxwfpqIGnE4naYzPyKPbDbv6k5lKDjmmHn2O7VzXQXimjE6sT3o=
=Dpjc
-END PGP SIGNATURE-
___
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: NFS mountd version 3 over TCP

[Steve Wills]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On 08/29/11 11:47, Rick Macklem wrote:
 I think it did. Lookup of .. was failing. I think that was because
 ni_strictrelative (added for capabilities) wasn't initialized and
 happened to be non-zero.
 
 Please try this patch and let us know if it helps:

That fixed it, thanks!

 Thanks for reporting this, I'm not sure when these fields not
 being initialized would have been noticed otherwise, rick

No problem, thanks for the quick response. If I see any other issues
I'll be sure to report them.

Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (FreeBSD)

iQEcBAEBAgAGBQJOXBlDAAoJEPXPYrMgexuhWzQH/AjTSRYzw93cn78BXwOpUVKJ
nS22ZH/fFdW6Jvaa/Ph1xHj6P04zjOlIrxTEIEnQvDlWKJkdnG/JwIuvOKFHmyiu
VpFBDReTNSPO3wN2t3pAOz89Kfs3mVkY1AvFly5RJ+CmZAzo/zafamS0UHICIm49
wSDb/KDo+hkEF+5Iluqsbm453wU0PiDjmPhlkvuFtGkn7kuuoU2r+inBFT5AzYlO
1iX79uKRJEywcaVFBbL4QiEVG6w/SWI+mUIy+TZmfAtaQGSQMJ2sEpGlcYSSzZ8E
4BLf9C2BPE+IWR8ssw1eF99+W39yCszpaauXhgwX1Tjrv/Ae0PBDONd4H1ejekQ=
=T0ct
-END PGP SIGNATURE-
___
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: NFS mountd version 3 over TCP

[Steve Wills]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/27/11 09:00, Rick Macklem wrote:
 This line indicates that mountd over tcp is registered for v3,
 so I suspect the error message is misleading??

Forgot to reply to this part, and I should have been more clear earlier.
When I used the default nfsd flags, it failed to startup, or exited
immediately on startup (not sure which). When I removed -u flag, it
started up and that message was replaced with the one about fsinfo
timeout. I can get the exact error message and tcpdump if you like. I
then added -o flag to nfsd (didn't put -u back) and then things seemed
to work OK.

Steve

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (FreeBSD)

iQEcBAEBAgAGBQJOWPPUAAoJEPXPYrMgexuhrLIH/jpRbAaKde9qi3xzsiIaZsuI
+O31ScAk+weud90cEjf/N9PwW5PfSJYHMO03hliMVGuOphkwYnpN2AStExzScfmm
nCFLz5UpzeKjznzirSOSNCGqwAyN3aPrghlyqNNi5eSkM9s0BdJgKBd+H9oSk7JE
7rf83Q2kPdqfvwhvRNpImC5oEXkZpExmitoIhESdnI/asr5OBwHIh8HthgIgMx+o
0t7v+togz0dT2jR7D+U1QbKhH5QP8pamjpP80D4TsO8P9pGt/PUuSBQAwDfQ3pjf
Tjnc2t9YMQ+hw3zqYTRrNCNMvaH7PlyAW0LvuW1Nhk8mus6HFxP1St/hgko+Y+8=
=Pdq4
-END PGP SIGNATURE-
___
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: NFS mountd version 3 over TCP

[Steve Wills]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/27/11 20:55, Rick Macklem wrote:
 I don't know why the nfsd wouldn't be able to bind(2) to port #2049 a
 second time for UDP, but someone on the net side might know? (Just in
 case it is a problem that has already been fixed, I'd try a newer kernel.)

Will do, see below.

 The new server was broken by r224778 on Aug. 11 and fixed by r224911 on
 Aug. 16. (I recall you mentioning Aug. 11?)

My kernel is from Aug 13, so definitely would fall into that range. I'll
update and rebuild and see how it goes.

Thanks!
Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (FreeBSD)

iQEcBAEBAgAGBQJOWZinAAoJEPXPYrMgexuhgp0H/1Dl9Bica8wbx5wLkkaPg5KM
Rf53qdAgi/TarcMxufN+ujqx1EBu02hsSfB0vx8B0EZ9Ta1qWA/b2aL8SHJsXZFB
gWPyr6sLINLcoaKGJ6Esp4QcIaU0PHOn4OhSGSMaZKYuMlXGsqJyJ3Wn6D46/4Re
CbxioTfNT3c85x/khSE3nOCKsxKddKmM+VtuOloNRji969QlYH/1ZWItxbg6Tr1m
hkT6v6hAM+EnvuLxlOJMTIegeec+WilIYSyP/FcuB2fcov1rdJSOOqOAUBHiBkRc
uz3ADLr1QhwVue7sSA2PNDo3jQhtA7HFQKrEnIAW1xQFKuuapdgxr/wSDu2+T30=
=5j1q
-END PGP SIGNATURE-
___
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

NFS mountd version 3 over TCP

[Steve Wills]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I'm trying to use 9.0-CURRENT as an NFS server for a VMWare ESXi 4.1.0.
When I attempt the mount, it logs this message:

The NFS server does not support MOUNT version 3 over TCP

Have I configured something wrong and if so what? Or is this something
related to the new NFS code?

Thanks,
Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (FreeBSD)

iQEcBAEBAgAGBQJOWEtYAAoJEPXPYrMgexuhWyAIAJ8Mfkjc8gtXxIYpbIDM2ECR
B6ke25NNJj4Q41a77gqPsUr6nIePwoa6LlBcTNtQxx8xtC3CobB/QBjiGSLqQKoF
cdcXj34tKE6e4cxptw+fYh7JXLalmmqd9BXgkKGf98UzXVDT0elIK7Ke/0thDp4s
SOPO8VZ6tdMgo98oONk7qmv8nR2OhnXuJVBRBIc+Xfppq23/5u2GNeaqiJRv3Ace
xVEusvPLAFtsCbyivoL27uqvJlNrA/cxA/VjzycYC+OhQ+deF3l8Ba0WNbVFSSjA
tDXjT3acrHiAw7iej7Kqs9G1sZByFvymTl86E449+o6Y+1hs2Xn/3POUwWfaCqU=
=U1iG
-END PGP SIGNATURE-
___
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: NFS mountd version 3 over TCP

[Steve Wills]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/26/11 21:41, Steve Wills wrote:
 Hi,
 
 I'm trying to use 9.0-CURRENT as an NFS server for a VMWare ESXi 4.1.0.
 When I attempt the mount, it logs this message:
 
 The NFS server does not support MOUNT version 3 over TCP
 
 Have I configured something wrong and if so what? Or is this something
 related to the new NFS code?

I guess a little more info would be helpful...

rc.conf has:

nfs_server_enable=YES
rpcbind_enable=YES
mountd_enable=YES
rpc_statd_enable=YES
rpc_lockd_enable=YES

/etc/exports contains, amongst others:

/boxy/vmware -alldirs -maproot=0:0 -network 10.0.1 -mask 255.255.255.0

rpcinfo shows:

   program version netid addressserviceowner
104tcp   0.0.0.0.0.111  rpcbindsuperuser
103tcp   0.0.0.0.0.111  rpcbindsuperuser
102tcp   0.0.0.0.0.111  rpcbindsuperuser
104udp   0.0.0.0.0.111  rpcbindsuperuser
103udp   0.0.0.0.0.111  rpcbindsuperuser
102udp   0.0.0.0.0.111  rpcbindsuperuser
104tcp6  ::.0.111   rpcbindsuperuser
103tcp6  ::.0.111   rpcbindsuperuser
104udp6  ::.0.111   rpcbindsuperuser
103udp6  ::.0.111   rpcbindsuperuser
104local /var/run/rpcbind.sock  rpcbindsuperuser
103local /var/run/rpcbind.sock  rpcbindsuperuser
102local /var/run/rpcbind.sock  rpcbindsuperuser
151udp6  ::.2.224   mountd superuser
153udp6  ::.2.224   mountd superuser
151tcp6  ::.2.224   mountd superuser
153tcp6  ::.2.224   mountd superuser
151udp   0.0.0.0.2.224  mountd superuser
153udp   0.0.0.0.2.224  mountd superuser
151tcp   0.0.0.0.2.224  mountd superuser
153tcp   0.0.0.0.2.224  mountd superuser

tcpdump here:

http://people.freebsd.org/~swills/nfs_debug.pcap

Suggestions appreciated, thanks!

Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (FreeBSD)

iQEcBAEBAgAGBQJOWFOLAAoJEPXPYrMgexuhCvoH/1ky5qXxfQhgTdtYEDbCsfo4
J3xiFG9es+ajpNa1LtqlaMBrvs5fxfv0F7bzklOvUKmsVE4FPuFrcOd6IvIwTw+T
U63UFocls3ZufNH+VjzxkFc5jfQ8hTDWXjKPfGMUxrCekt4pcEX4uze+I3YV/WRR
IFLTkfUCLvgEJSHn39Yl7ZmHud6kJaUUQv5ne8vWgd8KRNt4IWQqvqltYZDvwY1f
8ajYxJDwKOkVRMhRwh+4O0Fgs3Owar1W0JyNzmJ+Se9/QIVzTwQS6Q4l3jQjfSrU
YvRpMFQrb/ChZGZnH//FrXWhHK3TPg++XcRe1PGdY6KB+Fh1gjz+DRzbf5CzYBo=
=dp9s
-END PGP SIGNATURE-
___
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: NFS mountd version 3 over TCP

[Steve Wills]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/26/11 22:16, Steve Wills wrote:
 On 08/26/11 21:41, Steve Wills wrote:
 Hi,
 
 I'm trying to use 9.0-CURRENT as an NFS server for a VMWare ESXi 4.1.0.
 When I attempt the mount, it logs this message:
 
 The NFS server does not support MOUNT version 3 over TCP
 
 Have I configured something wrong and if so what? Or is this something
 related to the new NFS code?
 
 I guess a little more info would be helpful...
 
 rc.conf has:
 
 nfs_server_enable=YES
 rpcbind_enable=YES
 mountd_enable=YES
 rpc_statd_enable=YES
 rpc_lockd_enable=YES
 
 /etc/exports contains, amongst others:
 
 /boxy/vmware -alldirs -maproot=0:0 -network 10.0.1 -mask 255.255.255.0
 
 rpcinfo shows:
 
program version netid addressserviceowner
 104tcp   0.0.0.0.0.111  rpcbindsuperuser
 103tcp   0.0.0.0.0.111  rpcbindsuperuser
 102tcp   0.0.0.0.0.111  rpcbindsuperuser
 104udp   0.0.0.0.0.111  rpcbindsuperuser
 103udp   0.0.0.0.0.111  rpcbindsuperuser
 102udp   0.0.0.0.0.111  rpcbindsuperuser
 104tcp6  ::.0.111   rpcbindsuperuser
 103tcp6  ::.0.111   rpcbindsuperuser
 104udp6  ::.0.111   rpcbindsuperuser
 103udp6  ::.0.111   rpcbindsuperuser
 104local /var/run/rpcbind.sock  rpcbindsuperuser
 103local /var/run/rpcbind.sock  rpcbindsuperuser
 102local /var/run/rpcbind.sock  rpcbindsuperuser
 151udp6  ::.2.224   mountd superuser
 153udp6  ::.2.224   mountd superuser
 151tcp6  ::.2.224   mountd superuser
 153tcp6  ::.2.224   mountd superuser
 151udp   0.0.0.0.2.224  mountd superuser
 153udp   0.0.0.0.2.224  mountd superuser
 151tcp   0.0.0.0.2.224  mountd superuser
 153tcp   0.0.0.0.2.224  mountd superuser

As you might guess, this rpcinfo output indicates nfsd wasn't running. I
am seeing this:

can't bind udp addr *: Address already in use

in syslog. Setting this:

nfs_server_flags=-t -n 4

allowed it to startup, but it then timed out an fsinfo call. Adding -o
to the nfs_server_flags to use the old nfs server allowed vmware to
mount. FWIW, I can't find any reason for the udp message above, nothing
seems to be using it that I can find. Ideas? tcpdumps are available if
anyone want them.

Steve


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (FreeBSD)

iQEcBAEBAgAGBQJOWF6PAAoJEPXPYrMgexuhHPYIAJ6SVxtORDbesvU35ktAS/id
5iWyTWO3CTHXT42uP4IZBT1o2AWFu6e9wUX84YEZyujMln0E++8hZccaa8zQBJhr
febHkZxqPdQOo/mpg1ci5J70Hs1UBV9cxU3uOA83vxunOM6xwA0B+4krfflj/k7P
cPtpztmuepQQ8/S5hB5ajnfM/gFOh1f2uPwWTj2/5NSWMoVfN3f0539bh05XKfRa
4X7XKxN/J4HBRGaNjnL8IWu86AW60H9Q3gdisdtT0k9sK4X3DswmiRMlMt4M4rS8
oX0vrgruTiKZf+bsraYvhuo4JyselXMicTnW7rUOVx8jiNVVk1nymSVF1XDUOrw=
=MeJv
-END PGP SIGNATURE-
___
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: em problem in virtualbox since the weekend

[Steve Wills]

On 07/21/11 15:10, Scot Hetzel wrote:
 On Thu, Jul 21, 2011 at 10:53 AM, John Baldwin j...@freebsd.org wrote:
 Hmm, so there does look to be a reasonable _CRS method.  Oh, I think I see
 what I don't like:

DWordMemory (ResourceProducer, PosDecode, MinNotFixed, 
 MaxFixed, Cacheable, ReadWrite,
0x, // Granularity
0x, // Range Minimum
0xFFDF, // Range Maximum
0x, // Translation Offset
0x, // Length
,, _Y01, AddressRangeMemory, TypeStatic)

 
 This patch fixed the problem with my recent install of FreeBSD 9.0 on
 VirtualBox.
 
 Thanks for the fix.
 

Same here, thanks!

Steve
___
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: em problem in virtualbox since the weekend

[Steve Wills]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/20/11 09:04, John Baldwin wrote:
 On Wednesday, July 20, 2011 8:33:07 am Bernhard Froehlich wrote:
 On Wed, 20 Jul 2011 07:41:26 -0400, John Baldwin wrote:
 On Tuesday, July 19, 2011 10:35:42 pm Steve Wills wrote:
 Hi,

 While testing some other things, I found -CURRENT from yesterday doesn't
 work with the em0 in my VirtualBox 4.0.8 (a little out of date
 admittedly). It worked Friday or Saturday I think. Anyone else seen this
 or should I open a PR? Has the code changed or am I perhaps
 misremembering dates? The error reported is:

 em0: Unable to allocate bus resource: memory
 em0: Allocation of PCI resources failed

 This is due to a bug in VirtualBox's BIOS implementation.  Someone
 should file
 a bug report with VirtualBox to ask them to fix their BIOS.  The problem is 
 that they claim that the Host-PCI bridge in their system only decodes 
 addresses 0xa-0xb (i.e. the VGA window) via the Producer 
 resources 
 in the _CRS method of the Host-PCI bridge device.  This tells the OS
 that all
 the existing PCI devices are using invalid memory address ranges but that 
 there is also no available address space to allocate for PCI devices such 
 as 
 em0.

 You can workaround this by setting debug.acpi.disabled=hostres until 
 VirtualBox fixes their code.  I'm happy to provide further
 clarification to an
 existing VirtaulBox bug report if needed.

 Thanks a lot for the analysis! I've talked to one of the virtualbox
 developers about that but they are not aware of such problems with Linux
 or Windows guests yet. So they are currently unsure if it's a VirtualBox
 or FreeBSD fault and if it's their fault why it works fine with other
 guests. I'm also unsure because I haven't heard of that problem before
 and now multiple people complain. That looks more like a FreeBSD related
 problem on current or stable.

 I think it would be good if someone could try to reproduce that with
 emulators/virtualbox-ose-legacy which is 3.2.12 to get some vbox dev
 look into the problem again.
 
 FreeBSD just started honoring this setting in the BIOS this week and ignored
 it previously.  Can you get an acpidump from within VirtaulBox?  I might be
 able to point to a bug in it directly if so.
 

Thanks for the info! I've attached the acpidump and also posted a copy here:

http://people.freebsd.org/~swills/vbox-4.0.8.asl.gz

in case the mailing list eats it.

Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (FreeBSD)

iQEcBAEBAgAGBQJOJ1UoAAoJEPXPYrMgexuhhngIAJ/gyw1DMCciYDOw2Ek53dCb
Cx2zFFm32THagLFIewKSL7RDKr6fNcNWuAdfFm/zpKq8nGUjA16p9A4eoOvdVc5u
MhAu7oPZlnx9pX1o/JRjW0mtWglrHvKMapsptzlGOmS8PZMQz9s+L+IvGhsY8+qV
avQ0V/w/AwG+T7x/vaCPpPdDPubuxT7vO+A5x9r4aUtFbKWIzF/1rsbq3cjIiGXw
ExMpcdDBGRyLsPpB4fzhjb/drOQMJAkO2PnPPkWDociWCnC8Da/qCr6keD1lZPtD
wx0UnMd/pyzJKVAuf4+VcifABIJIZeRqStIH7CB1fOKhcT+HDwatbKrEFGSvEMs=
=COvj
-END PGP SIGNATURE-


vbox-4.0.8.asl.gz.sig
Description: Binary data
___
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

em problem in virtualbox since the weekend

[Steve Wills]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

While testing some other things, I found -CURRENT from yesterday doesn't
work with the em0 in my VirtualBox 4.0.8 (a little out of date
admittedly). It worked Friday or Saturday I think. Anyone else seen this
or should I open a PR? Has the code changed or am I perhaps
misremembering dates? The error reported is:

em0: Unable to allocate bus resource: memory
em0: Allocation of PCI resources failed

Thanks,
Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (FreeBSD)

iQEcBAEBAgAGBQJOJj7+AAoJEPXPYrMgexuhA0gIAIOevO4y79y+hvWkO/4ZvKJ2
bAMsaNbmp68vXkStLxm2nBa8UFUhjDtYu2qPh1Dj4PK/sx96swENkt4uJsyeBl12
5L6nLNR/A9LyWRhVKJE3QTcDOYKSCV93mjtm1sRTqrxYaZL05oE3isyRRj99c8AU
105wz+pO22h4CrJiNJQGb6G2CE4e4ghs6W5ToqxCdN5whZA6sjoeStzUnmnSKceS
05WzbGdoApbT4UknmDM9G4m8udHbCN2Lsk5rERug55F3eG6mrniJMd4EnrHC5FzW
wRFvx3PWNbDkSYNh1uy/EVic9sJ4IoAzKLWtlaHpqS56LxKPYsTkv1X0u3s2mfA=
=m0D7
-END PGP SIGNATURE-
___
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

responsiveness during IO tasks

[Steve Wills]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I've noticed lately that when doing heavy IO, my 9-CURRENT system (Fri
Apr 15 23:33:46 EDT 2011) is quite unresponsive. I have two ZFS mirrors
setup and run KDE4. The system has 12GB of RAM.

When I, for example, copy an ISO image from one mirror to the other, the
whole desktop becomes really slow during the copy. It takes a good 15
seconds to open a new tab in Konsole, switching windows takes a while,
etc. Once the copy is finished, things are fine. It wasn't like this
back before I upgraded from 8.2-RC1 to 9-CURRENT. Has anyone else
noticed something similar, or is it just me? Is there any other info I
can provide or something I should look for?

Thanks,
Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (FreeBSD)

iQEcBAEBAgAGBQJNtiDLAAoJEPXPYrMgexuh2hgIAK4a33NtKUNP5bDy9nCumjNM
Y+0WYxio72kDEUR0KPGJKB8TT3qV4DAknvydEvOTvXNQq2GZUX5WvJKu0cNwbg7g
qQt7xawaQq9NkE4dGJLMgDRDrkGVzHEFFHKegmFl8l9WnUxC8ffAjEvtW63Lcefe
xLzo9s3SbfmKS5p6dm/EXx49rSrtZv3uENnPBErXDY4Vd6LtNRBV2umk2GzU0Jgr
HdOcZVv+MOSEbIMavJidRtYE5Ous0XYRBYFF+ZHhRVkLQ4yIj2OXmQiB0IjYh11O
gX0NcHSBA8Pe6WbRRpcUbS0Evr4ur/n1VWgwZB/Bfbrtt0RnFbRDNCnBfOLAhuw=
=ZgkD
-END PGP SIGNATURE-
___
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: ipv6 / rtadv problem

[Steve Wills]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I have a similar issue. I have:

ifconfig_re0_ipv6=inet6 accept_rtadv

And after boot, I get:

% ping6 www.google.com
PING6(56=40+8+8 bytes) 2001:470:::::: --
2a00:1450:8005::68
^C
- --- www.l.google.com ping6 statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss

But, if I ping my gateway, things are fine:

% ping6 2001:470::::1
PING6(56=40+8+8 bytes) 2001:470:::::: --
2001:470::::1
16 bytes from 2001:470::::1, icmp_seq=0 hlim=64 time=1.037 ms
16 bytes from 2001:470::::1, icmp_seq=1 hlim=64 time=0.365 ms
^C
- --- 2001:470::::1 ping6 statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.365/0.701/1.037/0.336 ms

meatwad% ping6 www.google.com
PING6(56=40+8+8 bytes) 2001:470:::::: --
2a00:1450:8005::68
16 bytes from 2a00:1450:8005::68, icmp_seq=0 hlim=54 time=124.774 ms
16 bytes from 2a00:1450:8005::68, icmp_seq=1 hlim=54 time=123.641 ms
^C
- --- www.l.google.com ping6 statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 123.641/124.208/124.774/0.566 ms

%

I didn't have this problem in January.

Steve

On 03/28/11 08:55, Daniel O'Connor wrote:
 Hi,
 I am trying to get a -CURRENT box to get an IPv6 address via RTADV, however I 
 am not having any luck.
 
 I have tried the following in rc.conf :-
 ipv6_enable=YES
 ipv6_gateway_enable=YES
 
 ifconfig_em0_ipv6=RTADV
 
 (the last one I haven't seen before but it didn't seem to have an effect 
 anyway)
 
 ifconfig shows..
 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
   
 options=219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC
   ether 00:25:90:32:09:1e
   inet6 fe80::225:90ff:fe32:91e%em0 prefixlen 64 scopeid 0x2 
   inet 203.31.81.43 netmask 0xffc0 broadcast 203.31.81.63
   nd6 options=21PERFORMNUD,AUTO_LINKLOCAL
   media: Ethernet autoselect (100baseTX full-duplex)
   status: active
 
 I see rtadv packets on the network :-
 12:50:46.444380 IP6 fe80::204:61ff:fe79:276f  ff02::1: ICMP6, router 
 advertisement, length 56
 
 Other hosts can obtain a prefix just fine. This is the only 9.0 one, I have 
 other FreeBSD boxes but they are 8.x ish.
 
 --
 Daniel O'Connor software and network engineer
 for Genesis Software - http://www.gsoft.com.au
 The nice thing about standards is that there
 are so many of them to choose from.
   -- Andrew Tanenbaum
 GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
 
 
 
 
 
 
 ___
 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

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (FreeBSD)

iQEcBAEBAgAGBQJNlVJUAAoJEPXPYrMgexuhztQH/0lL3cvjapSAEI6ph+CjyTbB
Tm/WJdtpkUMLzW0wM8mDoLYHuXQcG4wv4QpQTcQM4Stk1869LY74nNFTkopk3pc6
TNEa7FfftrJnWGsN8f5HytOen8EGB+tXnSd6b1mXkbSUcJWKALQPFYptv5ssU5Ob
+vv2T8Bei77T1OIeDZeg2rFpWQ5IfKeLfzfvnsIKsX1x+QB2+gnWvcb7bWqNMBed
tgtVzU9buLSO6WefZl+Q3ykPvR5ARwdJPEzwkuYR0udFbnf6GJGsACsWI6GujfDH
skvHIrDNjY39jV+k2qZKF4x7HnbehwM21qZXnxHoMqepnVGIFpo8Y+sJb0mJk+8=
=XERs
-END PGP SIGNATURE-
___
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: ZFSv28 is in!

[Steve Wills]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/06/11 04:22, Edward Tomasz Napierała wrote:
 Wiadomość napisana przez Steve Wills w dniu 2011-03-06, o godz. 05:11:
 
 [..]
 
 Thanks for your work on this, I'm very happy to have ZFS v28. I just
 updated my -CURRENT system from a snapshot from about a month ago to
 code from today. I have 3 pools and one of them is for ports tinderbox.
 I only upgraded that pool. When I try to build something using
 tinderbox, I get this error:

 cp: failed to set acl entries for
 /usr/local/tinderbox/9-CURRENT-amd64-FreeBSD/buildscript: Operation not
 supported
 
 What does mount show?

/dev/md4 12186190 332724 11853466 3%
/usr/local/tinderbox/9-CURRENT-amd64-FreeBSD

Sorry, I forgot about the mdmfs hacks I had in my local tinderd. Without
them, it works fine. So the problem seems to be in mfs rather than zfs.

Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAEBAgAGBQJNc42wAAoJEPXPYrMgexuhYiwH/0k+HYFiWHgDlpbEZL5xEYHS
+ZlOZ19kW58A648iVbzuBgGWcQIEkylflJc23pigue+Qm5gvUR9PYZmr20hleCow
96pOxlQOyu1yJ/w90yJsfOTnVXfwdgEZWrHwiW+dDQp1YCGjnXqiocHT6gjukCNV
HSm6hEMI9YD5y75tVZVep/en6VmSwywsLlHEL5T8M+x1bsUUkawCltNUcbYLfJWS
NMuyG1ZudwscTj1bZHKyz+1bu5sToBj/w8aU7vASn5wvIjnKhMo/DDiCICyykbQ1
7Qa3i+BfG7ugvq6WxV7OiiCTYzx8f8R2D9QOtz6wmAPLkQbItRfdX7i0lxG+nig=
=h6fT
-END PGP SIGNATURE-
___
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: ACL issue (Was Re: HEADS UP: ZFSv28 is in!)

[Steve Wills]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/06/11 08:35, Steve Wills wrote:
 On 03/06/11 04:22, Edward Tomasz NapieraBa wrote:
 Wiadomo[ napisana przez Steve Wills w dniu 2011-03-06, o godz. 05:11:
 
 [..]
 
 Thanks for your work on this, I'm very happy to have ZFS v28. I just
 updated my -CURRENT system from a snapshot from about a month ago to
 code from today. I have 3 pools and one of them is for ports tinderbox.
 I only upgraded that pool. When I try to build something using
 tinderbox, I get this error:

 cp: failed to set acl entries for
 /usr/local/tinderbox/9-CURRENT-amd64-FreeBSD/buildscript: Operation not
 supported
 
 What does mount show?
 
 /dev/md4 12186190 332724 11853466 3%
 /usr/local/tinderbox/9-CURRENT-amd64-FreeBSD
 
 Sorry, I forgot about the mdmfs hacks I had in my local tinderd. Without
 them, it works fine. So the problem seems to be in mfs rather than zfs.

I should have said mdmfs, but all that's doing is running mdconfig and
newfs for me. I've reproduced the issue without mdmfs:

% mdconfig -a -t swap -s 12G -u 4
% newfs -m 0 -o time /dev/md4
[...]
% mount /dev/md4 /tmp/foobar
% cp -p /usr/local/tinderbox/scripts/lib/buildscript /tmp/foobar
cp: failed to set acl entries for /tmp/foobar/buildscript: Operation not
supported

Without -p it works fine. FWIW:

% getfacl /usr/local/tinderbox/scripts/lib/buildscript
# file: /usr/local/tinderbox/scripts/lib/buildscript
# owner: root
# group: wheel
owner@:--:--:deny
owner@:rwxp---A-W-Co-:--:allow
group@:-w-p--:--:deny
group@:r-x---:--:allow
 everyone@:-w-p---A-W-Co-:--:deny
 everyone@:r-x---a-R-c--s:--:allow

Any suggestions on where the problem could be?

Thanks,
Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAEBAgAGBQJNc52WAAoJEPXPYrMgexuhayoH/ROak0Vj2Ezh3t0ViqeZ8n/v
Pa60x/MDvHcoqtEUM6CQulvf88pAjat07JCwoZKf2qlNgZgrcoK5gPjSeDsN+9jW
LJxuFIyTOAmNxVC3FJgRuynTv06nAXDJu9f8psYVQS8EW56UQ9gmvKWNA3v80w2F
bre2qzHneA42+5ZvVLnK6sSMJ2IBoyk9F1FXamUsP74TKygDL3iijatWWROJ+lQ+
HdY+TnmKEkZcXbl5qhya4etpPOxKcuTCD/VqYvUJXqkseIny9SE60xVhGyQWlDkU
xEtjHQL8oRkc5CTHpCVJQMFiVGNFpBKutZq56wAaG0xgcDuWhvHJ3hcv8m93VYg=
=c86J
-END PGP SIGNATURE-
___
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: ACL issue (Was Re: HEADS UP: ZFSv28 is in!)

[Steve Wills]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/06/11 10:37, Jeremy Chadwick wrote:
 
 At first glance it looks like acl_set_fd_np(3) isn't working on an
 md-backed filesystem; specifically, it's returning EOPNOTSUPP.  You
 should be able to reproduce the problem by doing a setfacl on something
 in /tmp/foobar.
 
 Looking through src/bin/cp/utils.c, this is the code:
 
 420 if (acl_set_fd_np(dest_fd, acl, acl_type)  0) {
 421 warn(failed to set acl entries for %s, to.p_path);
 422 acl_free(acl);
 423 return (1);
 424 }
 
 EOPNOTSUPP for acl_set_fd_np(3) is defined as:
 
  [EOPNOTSUPP]   The file system does not support ACL retrieval.
 
 This would be referring to the destination filesystem.
 
 Looking through the md(4) source for references to EOPNOTSUPP, we do
 find some references:
 
 $ egrep -n -r EOPNOTSUPP|ENOTSUP /usr/src/sys/dev/md
 /usr/src/sys/dev/md/md.c:423:   return (EOPNOTSUPP);
 /usr/src/sys/dev/md/md.c:475:   error = EOPNOTSUPP;
 /usr/src/sys/dev/md/md.c:523:   return (EOPNOTSUPP);
 /usr/src/sys/dev/md/md.c:601:   return (EOPNOTSUPP);
 /usr/src/sys/dev/md/md.c:731:   error = EOPNOTSUPP;
 
 Line 423 is within mdstart_malloc(), and it returns EOPNOTSUPP on any
 BIO operation other than READ/WRITE/DELETE.  Line 475 is a continuation
 of that.
 
 Line 508 is within mdstart_vnode(), behaving effectively the same as
 line 423.  Line 601 is within mdstart_swap(), behaving effectively the
 same as line 423.
 
 Line 731 is within md_kthread(), and indicates only BIO operation
 BIO_GETATTR is supported.  This would not be an ACL attribute thing,
 but rather getting attributes of the backing device itself.  The code
 hints at that:
 
  722 if (bp-bio_cmd == BIO_GETATTR) {
  723 if ((sc-fwsectors  sc-fwheads 
  724 (g_handleattr_int(bp, GEOM::fwsectors,
  725 sc-fwsectors) ||
  726 g_handleattr_int(bp, GEOM::fwheads,
  727 sc-fwheads))) ||
  728 g_handleattr_int(bp, GEOM::candelete, 1))
  729 error = -1;
  730 else
  731 error = EOPNOTSUPP;
  732 } else {

Thanks for the investigation! So this seems to be a bug in md? That's
too bad, I was enjoying using it to make my tinderbox builds faster.

 This leaves me with some ideas; just tossing them out here...
 
 1. Maybe/somehow this is caused by swap being used as the backing
type/store for md(4)?  Try using mdconfig -t malloc -o reserve
instead, temporarily anyway.

Seems to be the same.

 2. Are you absolutely 100% sure the kernel you're using was built
with options UFS_ACL defined in it?  Doing a strings -a
/boot/kernel/kernel | grep UFS_ACL should suffice.
 

Yep, it does:

% strings -a /boot/kernel/kernel | grep UFS_ACL
options UFS_ACL

(My kernel config is just include GENERIC then a bunch of nooptions
for KDB, DDB, GDB, INVARIANTS, WITNESS, etc.)

Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAEBAgAGBQJNc7DxAAoJEPXPYrMgexuh3gsH/0L474FitZMdLLrTLiDiU7jR
D+9syg0boUYcWbv6pA1j1r8LvXMrw0rIxvZOPB4BauY/u8nL5n0YgDgv7tjb69+D
n/m7ce6r1tm6JtBSl/d+MIYfmcnj1E9B8ibgeGwPApKnhe4lmmyLpFHW98tcU1EL
Be+koxDiaKloryyfHrlcIfmSmXMUZ8lP7MFHfFeS39KbE+sf7xXHHLjFE7bcPSi4
qKyBFDcw/ykRjsrM3+YDIanhLUHg8ZjKhlrzbPUgMpzlXXe2QbmLkQELa9SmhVzH
juYywb7JOe5uHuefFQxnTLkSWuDjTlxLW6M+FuNEDejfA91sGIil7m+1nMcdCFg=
=nsSt
-END PGP SIGNATURE-
___
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: ACL issue (Was Re: HEADS UP: ZFSv28 is in!)

[Steve Wills]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/06/11 11:30, Jeremy Chadwick wrote:
 On Sun, Mar 06, 2011 at 08:23:42AM -0800, Jeremy Chadwick wrote:
 On Sun, Mar 06, 2011 at 11:06:09AM -0500, Steve Wills wrote:

 Sorry, I should have been more clear -- my investigation wasn't to
 determine if the issue you're reporting was a bug or not, but more along
 the lines of hmm, where is userland getting EOPNOTSUPP from in the
 kernel in this situation?  It could be that some piece hasn't been
 implemented somewhere yet (more an incomplete than a bug :-) ).

 I tend to trace source the way I did above in hopes that someone (kernel
 dev, etc.) will chime in and go Oh, yes, THAT... let me tell you about
 that!  It's also for educational purposes; I figure sharing the innards
 along with some simple descriptions might help people feel more
 comfortable (vs. thinking everything is a black box; don't let the magic
 smoke out!).  Sometimes digging through the code helps.

Definitely. I had started looking at cp(1) source, but got a bit lost.

 This leaves me with some ideas; just tossing them out here...

 1. Maybe/somehow this is caused by swap being used as the backing
type/store for md(4)?  Try using mdconfig -t malloc -o reserve
instead, temporarily anyway.

 Seems to be the same.

 I'm not too surprised, but at least that rules out swap vs.
 non-block-device stuff being somehow responsible.

 I'm not a user of ACLs myself, but Robert Watson might know what's up
 with this, or where to go looking.  I've CC'd him here.

 2. Are you absolutely 100% sure the kernel you're using was built
with options UFS_ACL defined in it?  Doing a strings -a
/boot/kernel/kernel | grep UFS_ACL should suffice.


 Yep, it does:

 % strings -a /boot/kernel/kernel | grep UFS_ACL
 options UFS_ACL

 (My kernel config is just include GENERIC then a bunch of nooptions
 for KDB, DDB, GDB, INVARIANTS, WITNESS, etc.)

 Cool, good to rule out the obvious.  Thanks.

 The only other thing I can think of off the top of my head would be to
 ktrace -t+ -i the cp -p, then provide output of kdump -s -t+ after.
 I wouldn't say go about this quite yet (it may not even help determine
 what's going on); maybe wait for Robert to take a look first.
 
 It would help if I actually added Robert to the CC list, wouldn't it?
 :-)
 

That's OK, kib@ enlightened me (via IRC) that the issue is that I failed
to enable NFSv4 ACLs on the FS. I had tried this, but somehow got an
error, and then when I tried again I had the wrong ACL type (POSIX.1e).

Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAEBAgAGBQJNc7mdAAoJEPXPYrMgexuhhZUIAId0nmh4YTJbjzv3NDmxXVt3
16ZIx+wOQON9Sln0vrpKIDJGk95KzvuLnbVBPg7Oxhaa11llkEeYFFqMEVWn6Esa
hqwDe5yYJYWWyF7ulCmHDbAE2gEF5q2rVy0KrV+aI9x5DLeB607dpmZqVV6TeQky
mQb1zOcw165galYhI3S4juPK6z5nq5pnTc+l05590CcAkWtxOFwQjlDZiQtrxdg2
YhFhtrMeGubRdKtJyG0r17kJzlGCBwIYBg7SgnmORVB64W0N0zkVcC+ZrIhioR6Z
FoucxqelZ4VDt6IlmxZ3DzTNUGKWulCeCrus8+lDBPL1M92AfFgMF89i5n0Ot8Y=
=302p
-END PGP SIGNATURE-
___
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: ACL issue (Was Re: HEADS UP: ZFSv28 is in!)

[Steve Wills]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/06/11 12:49, Edward Tomasz Napierała wrote:
 
 The above looks like old-style, canonical six trivial ACL.  Now,
 cp(1) shouldn't even try to copy the ACL in this case, since there
 is nothing to copy.  So, for some reason, something failed between
 cp(1), acl_is_trivial_np(3) and the kernel.
 
 What does ls -al /usr/local/tinderbox/scripts/lib/buildscript show?

It looks like:

- -rwxr-xr-x+ 1 root  wheel  12547 Feb  1 21:21
/usr/local/tinderbox/scripts/lib/buildscript

Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAEBAgAGBQJNc9IMAAoJEPXPYrMgexuhMmQH/jU7Zsay7fDmYP4UY60P63TH
Zbq3jyitlhgh3BNyibbbJ3O0OsEUWEJ+xO5jz04g32Kvv/NFWqQD9tPygkABeBb2
v50K/uOS8VskcMoJaxzkOIDz2Y/0PNKHo+/Cft7/hMbW1W5h7ebe7peKn7FA/F6R
MzFY6RMe6sY4x00gxpo/f3DQAB5VR6MqQl5SbDMUE8dP7ut5gUe9f+QvJPc2OgMA
thCLqxEfjKohWtpmuctr1c8Ap3UKvAAzwUVT6qs+CNidaxb3qzXLDyA9Z614GVAy
1WQxTsEtfiByMm6N1qUqIkNZNFmFSO0cEuRyK8Z4FJ0ZA5X4smk8gicATp/wAPQ=
=Y/S+
-END PGP SIGNATURE-
___
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: ZFSv28 is in!

[Steve Wills]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Pawel,

On 02/27/11 15:29, Pawel Jakub Dawidek wrote:
 Hi.
 
 I just committed ZFSv28 to HEAD.
 
 New major features:
 
 - Data deduplication.
 - Triple parity RAIDZ (RAIDZ3).
 - zfs diff.
 - zpool split.
 - Snapshot holds.
 - zpool import -F. Allows to rewind corrupted pool to earlier
   transaction group.
 - Possibility to import pool in read-only mode.
 
 PS. If you like my work, you help me to promote yomoli.com:)
 
   http://yomoli.com
   http://www.facebook.com/pages/Yomolicom/178311095544155
 

Thanks for your work on this, I'm very happy to have ZFS v28. I just
updated my -CURRENT system from a snapshot from about a month ago to
code from today. I have 3 pools and one of them is for ports tinderbox.
I only upgraded that pool. When I try to build something using
tinderbox, I get this error:

cp: failed to set acl entries for
/usr/local/tinderbox/9-CURRENT-amd64-FreeBSD/buildscript: Operation not
supported

If I delete the /usr/local/tinderbox/9-CURRENT-amd64-FreeBSD/ directory
then try to build, I get no errors. Could this be a bug in tinderbox or
something else? It was working fine before the update as far as I know.

Thanks,
Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAEBAgAGBQJNcwmPAAoJEPXPYrMgexuhoXUH/jelhA/5sebWUjp2mEQ3GWYj
GBIxM0H3v4kzRQ3CxQ3ACC/piXcDtF+j33KJl1032DgrijaWLs9kj1vdQd1ye5xc
A9qN4Ek++/w3+JoLWkyyzIyg2/glIy/VaVdzXClEjR5GC02M3QG62OwVYyKEHicC
7FzeFHVRw29Rs6Rael3vkGospXfo7ha8uhc8Dv+kqLnmeBEaTYllpjtyzd9DbM38
01DhMc6Yg0EWbOF4h1wL6dwQDGDc0aBlLV8IWft90wVtewZWAhVGhrCBWLAflPWn
X6lSg74PLryANaV7Vmk9MvR+9McCwCFstrVVCvAnAwlUYJ5Umo8h0uRWY5bt9mA=
=EMs5
-END PGP SIGNATURE-
___
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