Re: Networking panic on 12 - found the cause

[Eric van Gyzen]

On 2/12/19 8:53 AM, Pete French wrote:
> I found my panic. If I take everything out of rc.conf and loader.conf
> and sysctl.conf and boot the system it works fine when I add an IP
> address. If I add this one line to sysctl.conf
> 
> net.link.ether.inet.garp_rexmit_count=2
> 
> Then I get a panic when I configure the interface:
> 
> root@serpentine-passive:~ #  ifconfig igb0 inet 10.32.10.4/16 up
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x28
> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0x80c987f1
> stack pointer   = 0x28:0xfe4d5730
> frame pointer   = 0x28:0xfe4d5750
> 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 = 12 (swi4: clock (0))
> trap number = 12
> panic: page fault
> cpuid = 0
> time = 1549981620
> KDB: stack backtrace:
> #0 0x80bdfdc7 at kdb_backtrace+0x67
> #1 0x80b93fa3 at vpanic+0x1a3
> #2 0x80b93df3 at panic+0x43
> #3 0x8106a7bf at trap_fatal+0x35f
> #4 0x8106a819 at trap_pfault+0x49
> #5 0x81069e3e at trap+0x29e
> #6 0x810450c5 at calltrap+0x8
> #7 0x80c986f6 at ether_output+0x6b6
> #8 0x80d03354 at arprequest+0x4c4
> #9 0x80d0515c at garp_rexmit+0xbc
> #10 0x80bade19 at softclock_call_cc+0x129
> #11 0x80bae2f9 at softclock+0x79
> #12 0x80b57c57 at ithread_loop+0x1a7
> #13 0x80b54da2 at fork_exit+0x82
> #14 0x810460be at fork_trampoline+0xe

I see the same behavior on head (and stable/12).

(kgdb) f
#16 0x80ce5331 in ether_output_frame (ifp=0xf80003672800,
m=0xf8000c88b100) at /usr/src/sys/net/if_ethersubr.c:468
468 switch (pfil_run_hooks(V_link_pfil_head, , ifp, 
PFIL_OUT,

   0x80ce5321 <+81>:mov%gs:0x0,%rax
   0x80ce532a <+90>:mov0x500(%rax),%rax
=> 0x80ce5331 <+97>:mov0x28(%rax),%rax

I think this is part of the V_link_pfil_head.  I'm not very familiar
with vnet.  Does this need a CURVNET_SET(), maybe in garp_rexmit()?

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

Re: Not sure if this is the correct place.... (laptop, dual-boot EFI)

[Eric van Gyzen]

> 
> I'd like to repartition it to be able to dual boot it much as I do with
> my X220 (I wish I could ditch Windows entirely, but that is just not
> going to happen), but I'm not sure how to accomplish that in the EFI
> world -- or if it reasonably CAN be done in the EFI world.  Fortunately
> the BIOS has an option to turn off secure boot (which I surmise from
> reading the Wiki FreeBSD doesn't yet support) but I still need a means
> to select from some reasonably-friendly way *what* to boot.

Check out rEFInd:

https://www.rodsbooks.com/refind/

I use it to dual boot Win10 and FreeBSD with EFI.  The installation docs are 
pretty good.

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

Re: Ryzen issues on FreeBSD ? (with sort of workaround)

[Eric van Gyzen]

On 11/26/18 10:25 AM, Pete French wrote:
> Foolwing up an old thread I know, but my ssystem ahs been pretty stable
> until recently, when it started locking up about one a week at least.
> This co-incided with me doing two things to it:
> 
> 1) Doubling the amount of RAM in it to 16 gig, using RAM which runs a
> bit faster than the original sticks (2667 instead of 2400)
> 
> 2) Upgrading to FreeBSD 12 BET4
> 
> Now, I am really hoping the lockups are down to the RAM and that I just
> need to underclock it a bit, but I am a bit worried by the fact it
> happened the ame time as I went to 12. Has anyone else seen any issues
> under 12 when stable under 11?

My Ryzen has never run 11, but I have never seen a single problem on 12.
 As you suggest, it's probably due to the particular hardware
combination.  If updating the BIOS doesn't help, I agree that lowering
the memory clock is the best next step.

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

Re: Good motherboard for Ryzen (first-gen)

[Eric van Gyzen]

On 9/21/18 9:53 PM, Eric van Gyzen wrote:
I would like to build a Ryzen desktop.  Can anyone recommend a good 
motherboard?


I'm planning on a first-gen, because the second-gen has similar 
stability problems as the first-gen had, and AMD hasn't released errata 
for the second-gen yet (as far as I know...I would love to be wrong).


I would like to be a cool kid with a Threadripper, but I can't justify 
the cost, so I'm thinking maybe a Ryzen 7 with /only/ 8 cores.  :)


Ideally, I want an Intel NIC, ECC memory support, and a 3-year warranty.


Thanks for all the responses.  They were very helpful.  Here is what I 
ended up building:


Mobo:  ASUS Prime X470-Pro
CPU:   Ryzen 7 2700X 3.7GHz 8-Core
RAM:   Corsair Vengeance LPX 2 x 16GB DDR4-2666 PC4-21300 C16
Video: ASUS GeForce GTX 1060 6GB
Disk:  Samsung 970 EVO 500GB TLC NAND M.2 2280 PCIe NVMe 3.0 x4
PSU:   EVGA SuperNOVA G3 750 Watt 80 Plus Gold ATX
Fan:   Cooler Master Hyper 212 EVO Universal CPU Cooler

It's running FreeBSD head.  BIOS version is 4018 (2018-07-12).  So far, 
it has been perfectly stable.  No crashes, no lockups.  It has been my 
work-from-home desktop for just over a week now.  I'm overclocking the 
memory a little, but nothing else.  The NIC works.  The sound works, 
though I've only tested the rear analog output.  The video card works 
with the nvidia-driver, currently 390.87.  It's driving two 2560x1440 
monitors over HDMI.


The only problem so far:  I can't get NUMA enabled.  I've set Memory 
Interleave to "off", but the BIOS still doesn't generate an ACPI SRAT 
table.  I'm still working on this.


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

Good motherboard for Ryzen (first-gen)

[Eric van Gyzen]

I would like to build a Ryzen desktop.  Can anyone recommend a good 
motherboard?


I'm planning on a first-gen, because the second-gen has similar 
stability problems as the first-gen had, and AMD hasn't released errata 
for the second-gen yet (as far as I know...I would love to be wrong).


I would like to be a cool kid with a Threadripper, but I can't justify 
the cost, so I'm thinking maybe a Ryzen 7 with /only/ 8 cores.  :)


Ideally, I want an Intel NIC, ECC memory support, and a 3-year warranty.

Thanks in advance,

Eric

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

Re: gpart strangeness

[Eric van Gyzen]

On 8/21/18 1:30 PM, Mike Tancsa wrote:

There are 3 of these disks I found. Unfortunately, they all seem a
little different from the revision stamps on the board.  They are all
from PCEngines who generally seem to source quality products. This is in
an APU3


I have an APU2.  My disk is exactly like your 'good' disk, except for 
the serial number, obviously.  I don't have any trouble. Maybe you can 
update the firmware on your bad disk.  I have no idea how.


Eric

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

Re: Ryzen issues on FreeBSD ? (with sort of workaround)

[Eric van Gyzen]

On 06/18/2018 09:34, Pete French wrote:
> Preseumably in the slightly longer term these workarounds go into the
> actual kernel if it detects Ryzen ?

Yes, Kostik said he would code this into the kernel after he gets enough
feedback.

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

Re: KBI unexpexted change in stable/11 ?

[Eric van Gyzen]

On 03/28/2018 10:35, Slawa Olhovchenkov wrote:
> On Wed, Mar 28, 2018 at 10:29:10AM -0500, Eric van Gyzen wrote:
> 
>> On 03/28/2018 08:09, Slawa Olhovchenkov wrote:
>>> I am upgrade system to latest -STABLE and now see kernel crash:
>>>
>>> - loading virtualbox modules build on 11.1-RELEASE-p6
>>> - loading nvidia module build on 11.1-RELEASE-p6 and start xdm
>>>
>>> Is this expected? I am mean about loading modules builded on
>>> 11.1-RELEASE on any 11.1-STABLE.
>>
>> This is not expected.  Can you bisect to find the stable/11 commit that
>> broke this?
>>
>> If you can roll back to 11.1-RELEASE, you could probably just
>> buildkernel and installkernel from various points along stable/11.  That
>> would save a lot of time by avoiding buildworld.
> 
> r325665 is previos point and is good.
> r331615 crashed.
> Can I use some script for bisect?

I'm not aware of a script for this.  The only tool I've used is "git
bisect", which is very handy if you're already familiar with git.

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

Re: KBI unexpexted change in stable/11 ?

[Eric van Gyzen]

On 03/28/2018 08:09, Slawa Olhovchenkov wrote:
> I am upgrade system to latest -STABLE and now see kernel crash:
> 
> - loading virtualbox modules build on 11.1-RELEASE-p6
> - loading nvidia module build on 11.1-RELEASE-p6 and start xdm
> 
> Is this expected? I am mean about loading modules builded on
> 11.1-RELEASE on any 11.1-STABLE.

This is not expected.  Can you bisect to find the stable/11 commit that
broke this?

If you can roll back to 11.1-RELEASE, you could probably just
buildkernel and installkernel from various points along stable/11.  That
would save a lot of time by avoiding buildworld.

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

Re: Ryzen issues on FreeBSD ? (with sort of workaround)

[Eric van Gyzen]

On 02/12/2018 21:54, Peter Moody wrote:
>> I'm having really good luck with the kernel patch attached to this
>> message:
>> https://docs.freebsd.org/cgi/getmsg.cgi?fetch=417183+0+archive/2018/freebsd-hackers/20180211.freebsd-hackers
> 
> I'm new to this; what are the chances that this gets into -STABLE in
> the near future?

Pretty high, I imagine.  Add yourself to these to stay informed:

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

https://reviews.freebsd.org/D14347

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

Re: i386 with 4GB RAM: less than 2GB available on A2SAV (Intel Atom E3940)

[Eric van Gyzen]

On 01/28/2018 10:05, Dimitry Andric wrote:
> On 28 Jan 2018, at 15:57, Andre Albsmeier  wrote:
>> I have a lot of machines running with 4 GB physical RAM and, for
>> some reasons, I still have to use a 32 bits OS.
>>
>> All of them show something between 3 and 3.5 GB of RAM available
>> in dmesg but the brand new Supermicro A2SAV really shocked me:
>>
>> FreeBSD 11.1-STABLE #0: Mon Jan 15 06:57:10 CET 2018
>> ...
>> real memory  = 4294967296 (4096 MB)
>> avail memory = 1939558400 (1849 MB)
>> ...
>>
>> So do people have any ideas how I might get a bit closer to at least
>> 3 GB? I assume there are no FreeBSD knobs which might help but hope
>> dies last...
> 
> This is a common problem on i386.  Most likely some ranges are reserved
> for I/O mappings, such as video cards.  If you boot with -v, I think the
> kernel prints an overview of the physical ram chunks available?  I don't
> know of any other way to get such an overview.

sysctl machdep.smap on BIOS, machdep.efi_map on UEFI.

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

Re: Compile-time check for clock_nanosleep()

[Eric van Gyzen]

On 07/03/2017 15:28, Chris Ross wrote:
> 
>> On Jul 3, 2017, at 14:46, Kurt Jaeger  wrote:
>>
>> Use __FreeBSD_version from sys/param.h:
>>
>> https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/versions.html
> 
>   Thanks.  That looks great.  Also, for my specific case of the addition of 
> clock_nanosleep(), it looks from time.h like I could use "__POSIX_VISIBLE >= 
> 200112”.  Maybe that isn’t safe, since later looking at time.h on 11.0 and on 
> 11.1, the latter has a definition for clock_nanosleep() in that block, but 
> the former does not.

__POSIX_VISIBLE has a different purpose and can't be used for this.  It's part
of a way for the application to request a strict namespace of certain versions
of POSIX, ANSI C, etc.

>   Yeah, digging around it appears that stable/11/sys/sys/param.h at r316498 
> had __FreeBSD_version at 1100512, and it was raised to 1100513 in revision 
> 318197.  And, clock_nanosleep was MFC’d into 11-stable in-between the two, at 
> revision 317618.  So, not a precise match there, but >= 1100513 should be 
> safe.

Yes, this is exactly what you want.  Actually, what you /really/ want is for the
committer to remember to bump __FreeBSD_version when he added the call, but I
forgot.  :(

Cheers,

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

Re: if_iwm crashes kernel when loaded from /boot/loader.conf

[Eric van Gyzen]

On 04/07/2017 09:38, Tommi Pernila wrote:
> On Fri, 7 Apr 2017 at 16.27, Tomasz CEDRO  wrote:
> 
>> Hello,
>>
>> I noticed a problem when loading if_iwm from /boot/loader.conf kernel
>> crashes as it cannot load module firmware dead loop occurs. Adding
>> iwm8000Cfw before if_iwm does not help.
>>
>> Loading if_iwm on a running system works fine and gives operational wifi.
>>
>> Intel Corporation Wireless 8260 class=0x028000 card=0x10108086
>> chip=0x24f38086 rev=0x3a hdr=0x00
>>
>> --
>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> 
> 
> This has been happening to my Intel 8260 as well.
> It seems to be a known bug.
> 
> I circumvent it by manually loading the wifi modules after boot. This
> doesn't crash the system.
> 
> As a dirty hack? You could add the loading as a script and automatically
> load the modules when the FreeBSD is fully up and running.

$ grep kld_list /etc/defaults/rc.conf
#kld_list=""# Kernel modules to load after local disks are mounted

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

Re: Kernel panic on production system - what now?

[Eric van Gyzen]

On 03/24/2017 03:28, Patrick M. Hausen wrote:
> Hi all,
> 
> Mar 24 02:39:36 ph001 kernel: kernel trap 12 with interrupts disabled
> Mar 24 02:39:36 ph001 kernel: 
> Mar 24 02:39:36 ph001 kernel: 
> Mar 24 02:39:36 ph001 kernel: Fatal trap 12: page fault while in kernel mode
> Mar 24 02:39:37 ph001 kernel: cpuid = 8; apic id = 08
> Mar 24 02:39:37 ph001 kernel: fault virtual address   = 0x0
> Mar 24 02:39:37 ph001 kernel: fault code  = supervisor read data, 
> page not present
> Mar 24 02:39:37 ph001 kernel: instruction pointer = 
> 0x20:0x809a4330
> 
> I must admit that this is a "first" for me. So where do I go from here?
> There is "stuff" in /var/crash that has got the right timestamps, it seems ...

Start with:

# pkg install gdb
# kgdb712 /boot/kernel/kernel /var/crash/vmcore.0

The "712" above is the GDB version number, so it might be different on your
system.  In GDB:

(gdb) bt full

Post that output to this list, along with "uname -a".

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

Re: net.inet.udp.log_in_vain strange syslog reports

[Eric van Gyzen]

On 02/15/2017 08:56, Mark Martinec wrote:

In a similar vein, I noticed also the following in our logs,
with net.inet.tcp.log_in_vain=1.

Looks like messages got concatenated somehow:

Jan 25 01:37:53 mildred kernel: TCP: [2607:ff10:c5:509a::10]:26459 to
[2001:1470:ff80::80:16]:4911 tcpflags 0x2; tcp_input: Connection attempt to
closed TCP: [2607:ff10:c5:509a::10]:14898 to [2001:1470:ff80::80:16]:5222
tcpflags 0x2; tcp_input: Connection attempt to closed port


The length of the truncated "TCP:...closed" message is just under 128, which is 
the PRINTF_BUFR_SIZE as defined in sys/amd64/conf/GENERIC.  You could try 
increasing this value and rebuilding your kernel to see if that fixes the 
truncation.  Don't increase it very much, since it's used to declare a buffer on 
the stack, and stack space is quite limited.  For this case, 180 should be enough.


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

Re: HWPMC on SkyLake

[Eric van Gyzen]

On 02/09/2017 14:53, Derrick McKee wrote:
> I would like to use hwpmc on my desktop with a SkyLake processor.  However,
> I get an 'hwpc_core: unknown PMC architecture: 4' error whenever I run
> kldload hwpmc command.  There was a small thread about this error on the
> current mailing list last year[1], but I can't find any resolution about
> this.  Is there any new information?
> 
> [1]
> https://lists.freebsd.org/pipermail/freebsd-current/2016-June/061863.html
> 
> Version: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
> 
> 
>1. hwpc_core: unknown PMC architecture: 4
>2. hwpmc: SOFT/16/64/0x67
> 

This appears to be fixed by r311224 just last month:

https://svnweb.freebsd.org/base?view=revision=311224

https://reviews.freebsd.org/D9036

It was merged to stable/11 by r311960.  I don't see a merge to stable/10.

Cheers,

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

Re: GELI with integrity verification on swap

[Eric van Gyzen]

On 02/09/2017 08:51, Mark Martinec wrote:

2) During boot the log shows a short flurry of messages like:

kernel: GEOM_ELI: Device gpt/sw1.eli created.
kernel: GEOM_ELI: Encryption: AES-XTS 128
kernel: GEOM_ELI:  Integrity: HMAC/SHA256
kernel: GEOM_ELI: Crypto: software
kernel: GEOM_ELI: gpt/sw1.eli: Failed to authenticate 16384 bytes of data at
offset 11452985344.
kernel: GEOM_ELI: gpt/sw1.eli: Failed to authenticate 4096 bytes of data at
offset 11453235200.
kernel: GEOM_ELI: gpt/sw1.eli: Failed to authenticate 4096 bytes of data at
offset 11453239296.
kernel: GEOM_ELI: gpt/sw1.eli: Failed to authenticate 4096 bytes of data at
offset 11453239296.
kernel: GEOM_ELI: gpt/sw1.eli: Failed to authenticate 4096 bytes of data at
offset 11453239296.
kernel: GEOM_ELI: gpt/sw1.eli: Failed to authenticate 4096 bytes of data at
offset 11453235200.
kernel: GEOM_ELI: gpt/sw1.eli: Failed to authenticate 4096 bytes of data at
offset 4096.
kernel: GEOM_ELI: gpt/sw1.eli: Failed to authenticate 4096 bytes of data at
offset 0.
kernel: GEOM_ELI: gpt/sw1.eli: Failed to authenticate 4096 bytes of data at
offset 11453239296.
kernel: GEOM_ELI: gpt/sw1.eli: Failed to authenticate 8192 bytes of data at
offset 65536.
kernel: GEOM_ELI: gpt/sw1.eli: Failed to authenticate 8192 bytes of data at
offset 8192.
kernel: GEOM_ELI: gpt/sw1.eli: Failed to authenticate 8192 bytes of data at
offset 0.

which, according to geli(8) man page, could be normal, as these blocks were 
never
written to beforehand and contain random stuff. As the geli swap device is
supposed to be ephemeral (Flags: ONETIME, W-DETACH, AUTH, W-OPEN), there is
no way to initialize blocks on a swap device on boot. So, are these messages
really safe to be ignored?

Which brings us another, perhaps more important question: what business does
a kernel has to do READING from a swap device, blocks which never have been
written to before by this incarnation of the kernel???


I can't comment on the rest of your message, but these look like the normal 
"tasting" of a new provider.  Some geom classes are looking for metadata near 
the beginning and end of the provider to see if they contain a partition scheme, 
file system, or whatever that class should consume.


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

Re: net.inet.udp.log_in_vain strange syslog reports

[Eric van Gyzen]

On 02/06/2017 10:19, Mark Martinec wrote:
> 
> One minor nit:
> instead of a hack:
> 
> char src[4*sizeof "123"];
> char dst[4*sizeof "123"];
> 
> it would be cleaner and in sync with the equivalent code in
> sys/netinet6/udp6_usrreq.c
> to use the INET_ADDRSTRLEN constant (from sys/netinet/in.h, value 16):
> 
> char src[INET_ADDRSTRLEN];
> char dst[INET_ADDRSTRLEN];

Agreed.

> Hope the fix finds its way into 11.1 (or better yet, as a patch level in
> 10.0).
> Should I open a bug report?

It will quite likely get into 11.1.  As for a 10.x patch, you would have
to ask re@ (I think), but I doubt it.  These messages are really just
informative and can't be used for any filtering, since the source
address could be spoofed.

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

Re: net.inet.udp.log_in_vain strange syslog reports

[Eric van Gyzen]

On 02/02/2017 12:55, Mark Martinec wrote:

11.0-RELEASE-p7, net.inet.udp.log_in_vain=1

The following syslog entries seem to indicate some buffer overruns
in the reporting code (not all log lines are broken, just some).

(the actual failed connection attempts were indeed there,
it's just that the reported IP address is highly suspicious)

  Mark


Connection attempt to UDP 193.2.4.2:53 from 95.87.1521242:26375


There is no buffer overrun, so no cause for alarm.  The problem is concurrent 
usage of a single string buffer by multiple threads.  The buffer is inside 
inet_ntoa(), defined in sys/libkern/inet_ntoa.c.  In this case, it is called 
from udp_input().


Would you like to test the following patch?

Eric


diff --git a/sys/netinet/udp_usrreq.c b/sys/netinet/udp_usrreq.c
index 173c44c..ca2dda1 100644
--- a/sys/netinet/udp_usrreq.c
+++ b/sys/netinet/udp_usrreq.c
@@ -674,13 +674,13 @@ udp_input(struct mbuf **mp, int *offp, int proto)
INPLOOKUP_RLOCKPCB, ifp, m);
if (inp == NULL) {
if (udp_log_in_vain) {
-   char buf[4*sizeof "123"];
+   char src[4*sizeof "123"];
+   char dst[4*sizeof "123"];

-   strcpy(buf, inet_ntoa(ip->ip_dst));
log(LOG_INFO,
"Connection attempt to UDP %s:%d from %s:%d\n",
-   buf, ntohs(uh->uh_dport), inet_ntoa(ip->ip_src),
-   ntohs(uh->uh_sport));
+   inet_ntoa_r(ip->ip_dst, dst), ntohs(uh->uh_dport),
+   inet_ntoa_r(ip->ip_src, src), ntohs(uh->uh_sport));
}
UDPSTAT_INC(udps_noport);
if (m->m_flags & (M_BCAST | M_MCAST)) {
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Upgrading boot from GPT(BIOS) to GPT(UEFI)

[Eric van Gyzen]

On 12/16/2016 11:39, Slawa Olhovchenkov wrote:
> On Fri, Dec 16, 2016 at 06:08:34PM +0100, Fernando Herrero Carrón wrote:
> 
>> Hi everyone,
>>
>> A few months ago I got myself a new box and I have been happily running
>> FreeBSD on it ever since. I noticed that the boot was not as fast as I had
>> expected and I've realized that, while my disk is GPT partitioned, the boot
>> process is still BIOS based:
>>
>> % gpart show
>> =>   34  976773101  ada0  GPT  (466G)
>>  34  6- free -  (3.0K)
>>  40   1024 1  freebsd-boot  (512K)
>>1064984- free -  (492K)
>>2048   67108864 2  freebsd-swap  (32G)
>>67110912  909662208 3  freebsd-zfs  (434G)
>>   976773120 15- free -  (7.5K)
>>
>> I am reading uefi(8) and it looks like FreeBSD 11 should be able to boot
>> using UEFI straight into ZFS, so I am thinking of converting that
>> freebsd-boot partition to an EFI partition, creating a FAT filesystem and
>> copying /boot/boot.efi there.
>>
>> How good of an idea is that? Would it really be that simple or am I missing
>> something? My only reason for wanting to boot with UEFI is faster boot,
>> everything is working fine otherwise.
>>
>> Thanks in advance for your help.
> 
> I am also interesting by this case.
> I think expand freebsd-boot to about 1M (size of /boot/boot1.efifat),
> dding /boot/boot1.efifat and set to type to 'efi' may be enough. I am
> never tried this.

I expect that would work.  It's slightly risky, though, since it doesn't let you
fall back to BIOS boot if EFI doesn't work.

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

Re: Upgrading boot from GPT(BIOS) to GPT(UEFI)

[Eric van Gyzen]

On 12/16/2016 11:08, Fernando Herrero Carrón wrote:
> Hi everyone,
> 
> A few months ago I got myself a new box and I have been happily running
> FreeBSD on it ever since. I noticed that the boot was not as fast as I had
> expected and I've realized that, while my disk is GPT partitioned, the boot
> process is still BIOS based:
> 
> % gpart show
> =>   34  976773101  ada0  GPT  (466G)
>  34  6- free -  (3.0K)
>  40   1024 1  freebsd-boot  (512K)
>1064984- free -  (492K)
>2048   67108864 2  freebsd-swap  (32G)
>67110912  909662208 3  freebsd-zfs  (434G)
>   976773120 15- free -  (7.5K)
> 
> I am reading uefi(8) and it looks like FreeBSD 11 should be able to boot
> using UEFI straight into ZFS, so I am thinking of converting that
> freebsd-boot partition to an EFI partition, creating a FAT filesystem and
> copying /boot/boot.efi there.
> 
> How good of an idea is that? Would it really be that simple or am I missing
> something? My only reason for wanting to boot with UEFI is faster boot,
> everything is working fine otherwise.

I would recommend creating another partition for EFI instead of replacing your
freebsd-boot partition, in order to have a working fallback in case EFI boot
doesn't work.  You would need to steal some space from your swap partition.

Otherwise, it's a good idea, and it really is that simple.  I did exactly that
when I updated a machine to 11 and switched to EFI.

$ gpart show ada0
=>   34  500118125  ada0  GPT  (238G)
 34  6- free -  (3.0K)
 40   1024 1  freebsd-boot  (512K)
   1064   1600 2  efi  (800K)
   2664   10485144 4  freebsd-swap  (5.0G)
   10487808  489629696 3  freebsd-zfs  (233G)
  500117504655- free -  (328K)

$ sysctl machdep.bootmethod
machdep.bootmethod: UEFI

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

Re: Freebsd 11.0 RELEASE - ZFS deadlock

[Eric van Gyzen]

On 11/09/2016 07:48, Henri Hennebert wrote:
> I encounter a strange deadlock on
> 
> FreeBSD avoriaz.restart.bel 11.0-RELEASE-p3 FreeBSD 11.0-RELEASE-p3 #0 
> r308260:
> Fri Nov  4 02:51:33 CET 2016
> r...@avoriaz.restart.bel:/usr/obj/usr/src/sys/AVORIAZ  amd64
> 
> This system is exclusively running on zfs.
> 
> After 3 or 4 days, `periodic daily` is locked in the directory 
> /usr/local/news/bin
> 
> [root@avoriaz ~]# ps xa|grep find
> 85656  -  D0:01.13 find / ( ! -fstype local -o -fstype rdonly ) -prune
> -o ( -name [#,]* -o -name .#* -o -name a.out -o -nam
>   462  1  S+   0:00.00 grep find
> [root@avoriaz ~]# procstat -f 85656
>   PID COMMFD T V FLAGSREF  OFFSET PRO NAME
> 85656 find  text v r r---   -   - - /usr/bin/find
> 85656 find   cwd v d r---   -   - - /usr/local/news/bin
> 85656 find  root v d r---   -   - - /
> 85656 find 0 v c r---   3   0 - /dev/null
> 85656 find 1 p - rw--   1   0 - -
> 85656 find 2 v r -w--   7  17 - -
> 85656 find 3 v d r---   1   0 - /home/root
> 85656 find 4 v d r---   1   0 - /home/root
> 85656 find 5 v d rn--   1 533545184 - /usr/local/news/bin
> [root@avoriaz ~]#
> 
> If I try `ls /usr/local/news/bin` it is also locked.
> 
> After `shutdown -r now` the system remain locked after the line '0 0 0 0 0 0'
> 
> After a reset and reboot  I can access /usr/local/news/bin.
> 
> I delete this directory and reinstall the package `portupgrade -fu news/inn`
> 
> 5 days later `periodic daily`is locked on the same directory :-o
> 
> Any idea?

I can't help with the deadlock, but someone who _can_ help will probably ask for
the output of "procstat -kk PID" with the PID of the "find" process.

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

Re: Can't build 11-stable without BPF

[Eric van Gyzen]

On 09/30/2016 16:19, Dave Mischler wrote:
> When I remove the "device bpf" from the kernel configuration the
> resulting "make buildkernel KERNCONF=XXX" fails to compile in module
> lmc, source file if_lmc.c
> 
> The problem seems to be that DEV_BPF is not defined, but this is not
> tested for.

Thanks for the report.  I just fixed it in head.  I'll merge it to stable/11 in
a few days.

https://svnweb.freebsd.org/changeset/base/306567

Cheers,

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

Re: Status of PCIe Hotplug?

[Eric van Gyzen]

On 09/27/2016 08:57, Borja Marcos wrote:
> 
>> On 27 Sep 2016, at 15:48, Jan Henrik Sylvester  wrote:
>> 
>> On 09/27/2016 12:16, Borja Marcos wrote:
>>> I have noticed that the GENERIC kernel in 11-STABLE includes the
>>> PCI_HP option, and the hotplug bits seem to be present in the
>>> kernel, but I don’t see any userland support for it.
>>> 
>>> Is it somewhat complete and in that case am I missing something?
>> 
>> I do not know kind of userland support you mean. I just tried:
>> 
>> Plugging in my USB 3.0 ExpressCard while 11.0 is running, the
>> controller was detected and I was able to use USB devices with it.
>> Great.
> 
> Thanks :)
> 
> I was hoping (and I assume it’s the ultimate goal of the project) to
> be able to hot plug PCIe devices such as NVMe drives.
> 
> On Solaris you can replace them provided you power them off
> previously (there’s a command for that, “hotplug”).
> 
> On FreeBSD I’ve tried using devctl but powering off, disabling a
> device and enabling it again has led to a panic.
> 
> Interestingly, I disabled nvme0 using devctl and "nvmecontrol
> devlist" didn’t find any nvme controllers despite having 10
> controllers and 10 drives. However, the ZFS pool of 10 NVMe drives
> was working happily. Degraded of course, with one NVMe missing.

To my knowledge, all the necessary PCIe-layer code is present.  However,
that's just one layer:  Many drivers will likely need changes in order
to cope with surprise removal of their devices.

For that reason, HotPlug needs a lot of testing on a variety of
platforms.  The FreeBSD developer base is much smaller than its user
base, of course, so the variety of our testing is rather limited.  You
can help immensely by giving us detailed bug reports, either on a
mailing list or in Bugzilla.  For a panic, the panic messages and stack
trace of the current thread will be very helpful.  Complete crashinfo(8)
output would be great.

The most relevant userland tool is devctl, followed closely by devinfo
and pciconf.

In the case of Jan's USB 3.0 ExpressCard, it's possible that one or all
of the USB controller drivers (xhci, ehci, uhci) didn't cope with the
surprise removal of the controller.  Before removing the card, try
detaching the driver(s) with "devctl detach xhciN".  There might be more
than one device.  Use "pciconf -lc" to find the HotPlug-capable pcib
devices (bridges).  Use devinfo to find which one is your ExpressCard
slot and find all the devices attached to it.  Then use devctl to detach
the devices.  There could be a tree of devices; in that case, you can
usually start at the level immediately under pcibN; you don't need to
detach every device from the bottom up.  Once all the devices are
detached, you should be able to remove the card safely.

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

Re: Problem with nsswitch.conf

[Eric van Gyzen]

On 09/21/2016 12:21, Shawn Bakhtiar wrote:
> Good morning All,
>
> I'm trying to configure my server as an LDAP client. I installed the nslcd 
> service and it's working great.
>
> My problem is when I issue the command getent passwd it only returns the LDAP 
> user not the local users. 
>
> #
> # nsswitch.conf(5) - name service switch configuration file
> # $FreeBSD: releng/10.2/etc/nsswitch.conf 224765 2011-08-10 20:52:02Z dougb $
> #
> group: file ldap
> group_compat: nis ldap
> hosts: files dns
> networks: files
> passwd: file ldap
> passwd_compat: nis ldap
> shells: files 
> services: files 
> services_compat: nis
> protocols: files 
> rpc: files
>
>
> When I change the above group and passwd setting back to compat (which was 
> the default configuration) I get the local users but none of the ldap users 
> show up. In fact nslcd is not even called (i've checked by running it in 
> debug mode). So how do I configure nsswitch to use both the local /etc/passwd 
> file and the ldap. I need this because without it services will not start. IE 
> nslcd complains that nslcd is not a valid user when using the above 
> configuration.

It should be "files", plural.

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

Re: [Bug 211491] System hangs after "Uptime" on reboot with iSCSI, zfs, and altroot

[Eric van Gyzen]

On 08/10/16 10:19 AM, Kubilay Kocak wrote:
>> Furthermore, it's a new regression that will go into 11.0-RELEASE, so
>> getting some attention is a good thing.  I imagine this is why koobs@
>> CC'd stable@.
> 
> It was the original reporter CC'd, I added mfc-stable{10,11} flags in
> case the issue was in those branches.

Oh!  My apologies.  I misremembered.

(Hmmm...Bugzilla doesn't seem to record changes in the CC list).

> I'm very careful with cc'ing lists for src/base issues unless SNR is
> very high, high impact or it needs eyes now.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: [Bug 211491] System hangs after "Uptime" on reboot with iSCSI, zfs, and altroot

[Eric van Gyzen]

On 08/09/16 06:10 PM, bugzilla-nore...@freebsd.org wrote:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211491
> 
> --- Comment #13 from Ngie Cooper  ---
> Please don't add -current or -stable to bugs like this; it spams the list
> unnecessarily (this issue impacts users of iSCSI + ZFS -- which seems a bit
> niche right now)

I'm sorry that some people were annoyed, although I wouldn't call it
spam.  It's a discussion of a bug that affects -STABLE, so stable@ is
appropriate.

Furthermore, it's a new regression that will go into 11.0-RELEASE, so
getting some attention is a good thing.  I imagine this is why koobs@
CC'd stable@.

I thought it was limited to iSCSI, so I put that in the summary.
However, we now know that it is not limited to iSCSI.  I just updated
the summary accordingly.

Cheers,

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

Re: procstat -kk: Cannot allocate memory

[Eric van Gyzen]

On 03/08/2016 14:17, Garrett Wollman wrote:
> Sometimes when running "procstat -kk", I get the following error:
>
> procstat: sysctl: kern.proc.pid: 1044: Cannot allocate memory
>
> What is the condition that causes this?  Is there a static limit in
> procstat, or in the kernel, that needs to be increased?

"Cannot allocate memory" from sysctl usually means the requested data
grew between the two calls to sysctl.  In this case, perhaps there are
more stack frames during the second call than during the first. 
libprocstat should probably allocate a little more memory than the first
sysctl prescribed, in order to accommodate this growth.

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

Re: Dell NVMe issues

[Eric van Gyzen]

On 10/06/2015 11:10, Sean Kelly wrote:
>
>> On Oct 6, 2015, at 11:06 AM, Eric van Gyzen <e...@vangyzen.net 
>> <mailto:e...@vangyzen.net>> wrote:
>>
>> Try this:
>>
>>sysctl vfs.zfs.vdev.trim_on_init=0
>>zpool create tank mirror nvd[01]
>>
>
> That worked. So my guess is the controller/FreeBSD is timing out while zpool 
> asks the drive to TRIM all 1.6TB?

That would be my guess, yes, but I'll let the experts take it from here.

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

Re: Dell NVMe issues

[Eric van Gyzen]

On 10/06/2015 10:18, Sean Kelly wrote:
> Back in May, I posted about issues I was having with a Dell PE R630 with 
> 4x800GB NVMe SSDs. I would get kernel panics due to the inability to assign 
> all the interrupts because of 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199321 
> . Jim Harris helped 
> fix this issue so I bought several more of these servers, Including ones with 
> 4x1.6TB drives…
>
> while the new servers with 4x800GB drives still work, the ones with 4x1.6TB 
> drives do not. When I do a
>   zpool create tank mirror nvd0 nvd1 mirror nvd2 nvd3
> the command never returns and the kernel logs:
>   nvme0: resetting controller
>   nvme0: controller ready did not become 0 within 2000 ms
>
> I’ve tried several different things trying to understand where the actual 
> problem is.
> WORKS: dd if=/dev/nvd0 of=/dev/null bs=1m
> WORKS: dd if=/dev/zero of=/dev/nvd0 bs=1m
> WORKS: newfs /dev/nvd0
> FAILS: zpool create tank mirror nvd[01]
> FAILS: gpart add -t freebsd-zfs nvd[01] && zpool create tank mirror nvd[01]p1
> FAILS: gpart add -t freebsd-zfs -s 1400g nvd[01[ && zpool create tank 
> nvd[01]p1
> WORKS: gpart add -t freebsd-zfs -s 800g nvd[01] && zpool create tank nvd[01]p1
>
> NOTE: The above commands are more about getting the point across, not 
> validity. I wiped the disk clean between gpart attempts and used GPT.
>
> So it seems like zpool works if I don’t cross past ~800GB. But other things 
> like dd and newfs work.
>
> When I get the kernel messages about the controller resetting and then not 
> responding, the NVMe subsystem hangs entirely. Since my boot disks are not 
> NVMe, the system continues to work but no more NVMe stuff can be done. 
> Further, attempting to reboot hangs and I have to do a power cycle.
>
> Any thoughts on what the deal may be here?
>
> 10.2-RELEASE-p5
>
> nvme0@pci0:132:0:0: class=0x010802 card=0x1f971028 chip=0xa820144d 
> rev=0x03 hdr=0x00
> vendor = 'Samsung Electronics Co Ltd'
> class  = mass storage
> subclass   = NVM

Try this:

sysctl vfs.zfs.vdev.trim_on_init=0
zpool create tank mirror nvd[01]

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

Re: Routing stops working when we create a new vlan

[Eric van Gyzen]

On 08/06/2015 22:09, Marcelo Gondim wrote:

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

 The output of ifconfig and netstat -nr -f inet, before and after you 
 create the new vlan, would be most helpful.

 Eric

 Hi Eric,
 
 I put the information you requested in PR.

Wow, the only difference in the output is the new vlan interface.  This is odd. 
 I'm afraid I have no ideas off-hand, and I don't have enough spare cycles to 
dive in.

Best of luck.

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

Re: Routing stops working when we create a new vlan

[Eric van Gyzen]

On 8/6/15 5:57 PM, Marcelo Gondim wrote:

Hi all,

Let me illustrate a network topology, to tell where the problem occurs:

PC station: 192.168.8.253/24 (FreeBSD 10.2-PRERELEASE)

Router: 192.168.8.177/24 and 10.254.215.1/24 (FreeBSD 10.2-RC2)

router(CPE): 10.254.215.188/24 (a customer)

From Router:
===

# ifconfig vlan201
vlan201: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
options=103RXCSUM,TXCSUM,TSO4
ether 70:71:bc:87:31:2d
inet 10.254.215.1 netmask 0xff00 broadcast 10.254.215.255
inet6 fe80::7271:bcff:fe87:312d%vlan201 prefixlen 64 scopeid 0x1a
nd6 options=21PERFORMNUD,AUTO_LINKLOCAL
media: Ethernet autoselect (1000baseT full-duplex)
status: active
vlan: 201 parent interface: em0

From PC station (192.168.8.253):
===

# ping -c 5 10.254.215.188
PING 10.254.215.188 (10.254.215.188): 56 data bytes
64 bytes from 10.254.215.188: icmp_seq=0 ttl=127 time=1.012 ms
64 bytes from 10.254.215.188: icmp_seq=1 ttl=127 time=0.864 ms
64 bytes from 10.254.215.188: icmp_seq=2 ttl=127 time=1.084 ms
64 bytes from 10.254.215.188: icmp_seq=3 ttl=127 time=1.618 ms
64 bytes from 10.254.215.188: icmp_seq=4 ttl=127 time=1.006 ms

--- 10.254.215.188 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.864/1.117/1.618/0.261 ms

It works perfectly.

Now I'm going on the router and I just create a new vlan 202.

From Router:
===

# ifconfig vlan202 create
#

At that moment my PC station stops to ping the IP 10.254.215.188.

From PC station (192.168.8.253):
===

# ping -c 5 10.254.215.188
PING 10.254.215.188 (10.254.215.188): 56 data bytes

--- 10.254.215.188 ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss

For all work again I need to restart the router.
I don't know if I could correctly explain the problem.

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


The output of ifconfig and netstat -nr -f inet, before and after you create 
the new vlan, would be most helpful.

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

Re: makefs Sparse Files: NetBSD CLI Compatibility

[Eric van Gyzen]

On 08/14/2013 10:13, Eric van Gyzen wrote:
 On 08/14/2013 09:53, Glen Barber wrote:
 On Wed, Aug 14, 2013 at 09:33:01AM -0500, Eric van Gyzen wrote:
 On 08/14/2013 09:06, Glen Barber wrote:
 On Wed, Aug 14, 2013 at 08:10:41AM -0500, Eric van Gyzen wrote:
 NetBSD's makefs has a -Z flag to create the image as a sparse file.  In
 FreeBSD, the flag is spelled -p.  Is there a reason for using a
 different flag?  It would be very nice to preserve CLI compatibility
 with NetBSD.

 NetBSD committed first (by one month), and neither change has gone into
 a release yet, so we should change to match NetBSD.  We should do it
 soon, too, since our change will go into 9.2-RELEASE.

 If we agree, I'll gladly make the patches, trivial though they'll be.

 Can you please try the attached patch?
 Thanks, Glen.  That patch would work.  However, since our -p flag has
 not yet gone into a release, there is no need to keep it.  I suggest
 that we simply rename -p to -Z, to match NetBSD.  The attached patch
 does this.

 Not in a release, no, but it is available in stable/ branches.  I'd
 prefer to deprecate the '-p' but keep the option for now, as we have no
 way to know how many people are using it.
 That's reasonable.  The attached patch, for releng/9.2, does this.  We
 could remove -p in head (by using my previous patch).

Is there any chance this will be fixed in 9.2?  It would be nice to
avoid introducing incompatibility in a release.

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

makefs Sparse Files: NetBSD CLI Compatibility

[Eric van Gyzen]

NetBSD's makefs has a -Z flag to create the image as a sparse file.  In
FreeBSD, the flag is spelled -p.  Is there a reason for using a
different flag?  It would be very nice to preserve CLI compatibility
with NetBSD.

NetBSD committed first (by one month), and neither change has gone into
a release yet, so we should change to match NetBSD.  We should do it
soon, too, since our change will go into 9.2-RELEASE.

If we agree, I'll gladly make the patches, trivial though they'll be.

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

Re: makefs Sparse Files: NetBSD CLI Compatibility

[Eric van Gyzen]

On 08/14/2013 09:06, Glen Barber wrote:
 On Wed, Aug 14, 2013 at 08:10:41AM -0500, Eric van Gyzen wrote:
 NetBSD's makefs has a -Z flag to create the image as a sparse file.  In
 FreeBSD, the flag is spelled -p.  Is there a reason for using a
 different flag?  It would be very nice to preserve CLI compatibility
 with NetBSD.

 NetBSD committed first (by one month), and neither change has gone into
 a release yet, so we should change to match NetBSD.  We should do it
 soon, too, since our change will go into 9.2-RELEASE.

 If we agree, I'll gladly make the patches, trivial though they'll be.

 Can you please try the attached patch?

Thanks, Glen.  That patch would work.  However, since our -p flag has
not yet gone into a release, there is no need to keep it.  I suggest
that we simply rename -p to -Z, to match NetBSD.  The attached patch
does this.

Eric
diff --git a/usr.sbin/makefs/makefs.8 b/usr.sbin/makefs/makefs.8
index 4d81e45..fd8d76d 100644
--- a/usr.sbin/makefs/makefs.8
+++ b/usr.sbin/makefs/makefs.8
@@ -43,7 +43,7 @@
 .Nd create a file system image from a directory tree or a mtree manifest
 .Sh SYNOPSIS
 .Nm
-.Op Fl Dpx
+.Op Fl DxZ
 .Op Fl B Ar byte-order
 .Op Fl b Ar free-blocks
 .Op Fl d Ar debug-mask
@@ -190,8 +190,6 @@ Set file system specific options.
 .Ar fs-options
 is a comma separated list of options.
 Valid file system specific options are detailed below.
-.It Fl p
-Create the image as a sparse file.
 .It Fl S Ar sector-size
 Set the file system sector size to
 .Ar sector-size .
@@ -213,6 +211,8 @@ ISO 9660 file system.
 .El
 .It Fl x
 Exclude file system nodes not explicitly listed in the specfile.
+.It Fl Z
+Create the image as a sparse file.
 .El
 .Pp
 Where sizes are specified, a decimal number of bytes is expected.
diff --git a/usr.sbin/makefs/makefs.c b/usr.sbin/makefs/makefs.c
index 03ff1ac..7cbf05a 100644
--- a/usr.sbin/makefs/makefs.c
+++ b/usr.sbin/makefs/makefs.c
@@ -113,7 +113,7 @@ main(int argc, char *argv[])
 	start_time.tv_sec = start.tv_sec;
 	start_time.tv_nsec = start.tv_usec * 1000;
 
-	while ((ch = getopt(argc, argv, B:b:Dd:f:F:M:m:N:o:ps:S:t:x)) != -1) {
+	while ((ch = getopt(argc, argv, B:b:Dd:f:F:M:m:N:o:s:S:t:xZ)) != -1) {
 		switch (ch) {
 
 		case 'B':
@@ -204,9 +204,6 @@ main(int argc, char *argv[])
 			}
 			break;
 		}
-		case 'p':
-			fsoptions.sparse = 1;
-			break;
 
 		case 's':
 			fsoptions.minsize = fsoptions.maxsize =
@@ -233,6 +230,10 @@ main(int argc, char *argv[])
 			fsoptions.onlyspec = 1;
 			break;
 
+		case 'Z':
+			fsoptions.sparse = 1;
+			break;
+
 		case '?':
 		default:
 			usage();
@@ -354,7 +355,7 @@ usage(void)
 	fprintf(stderr,
 usage: %s [-t fs-type] [-o fs-options] [-d debug-mask] [-B endian]\n
 \t[-S sector-size] [-M minimum-size] [-m maximum-size] [-s image-size]\n
-\t[-b free-blocks] [-f free-files] [-F mtree-specfile] [-px]\n
+\t[-b free-blocks] [-f free-files] [-F mtree-specfile] [-DxZ]\n
 \t[-N userdb-dir] image-file directory | manifest [extra-directory ...]\n,
 	prog);
 	exit(1);
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: makefs Sparse Files: NetBSD CLI Compatibility

[Eric van Gyzen]

On 08/14/2013 09:53, Glen Barber wrote:
 On Wed, Aug 14, 2013 at 09:33:01AM -0500, Eric van Gyzen wrote:
 On 08/14/2013 09:06, Glen Barber wrote:
 On Wed, Aug 14, 2013 at 08:10:41AM -0500, Eric van Gyzen wrote:
 NetBSD's makefs has a -Z flag to create the image as a sparse file.  In
 FreeBSD, the flag is spelled -p.  Is there a reason for using a
 different flag?  It would be very nice to preserve CLI compatibility
 with NetBSD.

 NetBSD committed first (by one month), and neither change has gone into
 a release yet, so we should change to match NetBSD.  We should do it
 soon, too, since our change will go into 9.2-RELEASE.

 If we agree, I'll gladly make the patches, trivial though they'll be.

 Can you please try the attached patch?
 Thanks, Glen.  That patch would work.  However, since our -p flag has
 not yet gone into a release, there is no need to keep it.  I suggest
 that we simply rename -p to -Z, to match NetBSD.  The attached patch
 does this.

 Not in a release, no, but it is available in stable/ branches.  I'd
 prefer to deprecate the '-p' but keep the option for now, as we have no
 way to know how many people are using it.

That's reasonable.  The attached patch, for releng/9.2, does this.  We
could remove -p in head (by using my previous patch).

Thanks for your help during this busy time in the release.

Eric
diff --git a/usr.sbin/makefs/makefs.8 b/usr.sbin/makefs/makefs.8
index 81bf334..75b2b8e 100644
--- a/usr.sbin/makefs/makefs.8
+++ b/usr.sbin/makefs/makefs.8
@@ -43,7 +43,7 @@
 .Nd create a file system image from a directory tree or a mtree manifest
 .Sh SYNOPSIS
 .Nm
-.Op Fl Dpx
+.Op Fl DxZ
 .Op Fl B Ar byte-order
 .Op Fl b Ar free-blocks
 .Op Fl d Ar debug-mask
@@ -191,7 +191,10 @@ Set file system specific options.
 is a comma separated list of options.
 Valid file system specific options are detailed below.
 .It Fl p
-Create the image as a sparse file.
+[Deprecated:  Use
+.Fl Z
+instead] Create the image as a sparse file.
+This flag is provided for compatibility with the stable/9 branch.
 .It Fl S Ar sector-size
 Set the file system sector size to
 .Ar sector-size .
@@ -213,6 +216,8 @@ ISO 9660 file system.
 .El
 .It Fl x
 Exclude file system nodes not explicitly listed in the specfile.
+.It Fl Z
+Create the image as a sparse file.
 .El
 .Pp
 Where sizes are specified, a decimal number of bytes is expected.
diff --git a/usr.sbin/makefs/makefs.c b/usr.sbin/makefs/makefs.c
index 03ff1ac..9125b40 100644
--- a/usr.sbin/makefs/makefs.c
+++ b/usr.sbin/makefs/makefs.c
@@ -113,7 +113,7 @@ main(int argc, char *argv[])
 	start_time.tv_sec = start.tv_sec;
 	start_time.tv_nsec = start.tv_usec * 1000;
 
-	while ((ch = getopt(argc, argv, B:b:Dd:f:F:M:m:N:o:ps:S:t:x)) != -1) {
+	while ((ch = getopt(argc, argv, B:b:Dd:f:F:M:m:N:o:ps:S:t:xZ)) != -1) {
 		switch (ch) {
 
 		case 'B':
@@ -233,6 +233,10 @@ main(int argc, char *argv[])
 			fsoptions.onlyspec = 1;
 			break;
 
+		case 'Z':
+			fsoptions.sparse = 1;
+			break;
+
 		case '?':
 		default:
 			usage();
@@ -354,7 +358,7 @@ usage(void)
 	fprintf(stderr,
 usage: %s [-t fs-type] [-o fs-options] [-d debug-mask] [-B endian]\n
 \t[-S sector-size] [-M minimum-size] [-m maximum-size] [-s image-size]\n
-\t[-b free-blocks] [-f free-files] [-F mtree-specfile] [-px]\n
+\t[-b free-blocks] [-f free-files] [-F mtree-specfile] [-DxZ]\n
 \t[-N userdb-dir] image-file directory | manifest [extra-directory ...]\n,
 	prog);
 	exit(1);
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: makefs Sparse Files: NetBSD CLI Compatibility

[Eric van Gyzen]

On 08/14/2013 14:05, Simon J. Gerraty wrote:
 On Wed, 14 Aug 2013 08:10:41 -0500, Eric van Gyzen writes:
 NetBSD's makefs has a -Z flag to create the image as a sparse file.  In
 FreeBSD, the flag is spelled -p.  Is there a reason for using a
 different flag?  
 No, the -p should have been dropped before we committed to FreeBSD.
 But it is there, and Glen expressed a desire to leave it working.

 I expect you could drop -p from the man page and usage message.
 Ie. just document -Z, but leave -p active, and no harm should
 result.

Thank you, Simon.  Later in this thread, I included a patch for 9.x to
do essentially that, and a patch for head to use only -Z and remove -p
entirely (since it was never in a release).  I think I'm just waiting
for someone to commit them, since I don't have a commit bit.

Cheers,

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

Re: unexpected idprio 31 behavior on 9.2-BETA2 and 9.2-RC1

[Eric van Gyzen]

On 08/06/2013 14:23, J David wrote:
 On Tue, Aug 6, 2013 at 1:59 PM, Eric van Gyzen e...@vangyzen.net wrote:
 on an otherwise idle amd64 system with 4 CPUs.  The first command in the
 build.log file:

 rm -rf /usr/obj/home/freebsd/tmp

 took over three minutes.  It should have taken about three /seconds/.

 uptime reported a load average of around 1.00.
 top showed no threads (user or kernel) using CPU.
 iostat showed an average of less than 20 tps on ada0.
 rm was usually in the RUN state.
 We are looking at something similar.  Would you be able to try to
 reproduce it using a kernel with:

 nooptions SCHED_ULE
 options   SCHED_4BSD

 to see if it makes a difference?  It seems to, but the problem is
 inconsistent enough that I can't be sure.

The 4BSD scheduler does //not// exhibit this problem.  I tested with the
latest releng/9.2 (r254054) and an otherwise GENERIC config.

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

Re: unexpected idprio 31 behavior on 9.2-BETA2 and 9.2-RC1

[Eric van Gyzen]

On 08/08/2013 09:19, Eric van Gyzen wrote:
 On 08/06/2013 14:23, J David wrote:
 On Tue, Aug 6, 2013 at 1:59 PM, Eric van Gyzen e...@vangyzen.net wrote:
 on an otherwise idle amd64 system with 4 CPUs.  The first command in the
 build.log file:

 rm -rf /usr/obj/home/freebsd/tmp

 took over three minutes.  It should have taken about three /seconds/.

 uptime reported a load average of around 1.00.
 top showed no threads (user or kernel) using CPU.
 iostat showed an average of less than 20 tps on ada0.
 rm was usually in the RUN state.
 We are looking at something similar.  Would you be able to try to
 reproduce it using a kernel with:

 nooptionsSCHED_ULE
 options  SCHED_4BSD

 to see if it makes a difference?  It seems to, but the problem is
 inconsistent enough that I can't be sure.
 The 4BSD scheduler does //not// exhibit this problem.  I tested with the
 latest releng/9.2 (r254054) and an otherwise GENERIC config.

To be thorough, I built a GENERIC kernel at the same rev, and it still
exhibits the problem.

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

Re: unexpected idprio 31 behavior on 9.2-BETA2 and 9.2-RC1

[Eric van Gyzen]

On 08/07/2013 04:09, Andriy Gapon wrote:
 on 06/08/2013 00:15 Dave Mischler said the following:
 I have an i5-2500 machine 8GB RAM now running 9.2-RC1 amd64 with the
 GENERIC kernel. Today, while still running 9.2-BETA2, I updated my
 source tree and started building world with idprio 31 and I looked back
 a while later and all the CPU cores and disk were essentially idle, and
 hardly any progress had been made on the build. I stopped and restarted
 the build without the idle priority setting and it ran fine. Anybody
 else seen any of this? Anybody know about any fairly recent changes that
 might account for it?

 I did a rm -rf /usr/src /usr/obj and loaded a new source tree before
 going to RC1.  I still see odd behavior at RC1.  Sometimes it works just
 like it should (i.e. compute bound processes use most/all of the
 available CPU time), but a lot of the time both the CPU and disk are
 idle (e.g. CPU 97.8% idle, disk 1% busy per systat).  I don't think I
 ever saw this behavior before while running make buildworld -j4.  Can
 anyone else confirm/rebut my findings?  Thanks.
 Are you sure that you really want to use idprio for a goal you want to 
 achieve?
 If yes, are you sure that you want to use idprio 31 specifically?
 With sched_ule idprio 31 is equivalent to priority of a completely idle 
 system.
  So the scheduler is in its right to run the idle (do nothing) thread 
 instead
 of your thread(s).

That sounds like a bug to me, or a POLA violation at least.  A user
thread should never have the same priority as the idle threads, because
a user thread, by definition, has work to do.

From the rtprio(1) examples:

 To make depend while not disturbing other machine usage:
   idprio 31 make depend

 P.S.
 https://wiki.freebsd.org/AvgThreadPriorityRanges

Nice!  Thank you for writing it and sending the link.

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

Re: unexpected idprio 31 behavior on 9.2-BETA2 and 9.2-RC1

[Eric van Gyzen]

On 08/05/2013 16:15, Dave Mischler wrote:
 I have an i5-2500 machine 8GB RAM now running 9.2-RC1 amd64 with the
 GENERIC kernel. Today, while still running 9.2-BETA2, I updated my
 source tree and started building world with idprio 31 and I looked back
 a while later and all the CPU cores and disk were essentially idle, and
 hardly any progress had been made on the build. I stopped and restarted
 the build without the idle priority setting and it ran fine. Anybody
 else seen any of this? Anybody know about any fairly recent changes that
 might account for it?

 I did a rm -rf /usr/src /usr/obj and loaded a new source tree before
 going to RC1.  I still see odd behavior at RC1.  Sometimes it works just
 like it should (i.e. compute bound processes use most/all of the
 available CPU time), but a lot of the time both the CPU and disk are
 idle (e.g. CPU 97.8% idle, disk 1% busy per systat).  I don't think I
 ever saw this behavior before while running make buildworld -j4.  Can
 anyone else confirm/rebut my findings?  Thanks.

I can confirm your findings, on 9.1-RELEASE-p5 amd64 GENERIC.

I ran

$ idprio 31 make buildworld buildkernel  /tmp/build.log 21 
/dev/null 

on an otherwise idle amd64 system with 4 CPUs.  The first command in the
build.log file:

rm -rf /usr/obj/home/freebsd/tmp

took over three minutes.  It should have taken about three /seconds/.

uptime reported a load average of around 1.00.
top showed no threads (user or kernel) using CPU.
iostat showed an average of less than 20 tps on ada0.
rm was usually in the RUN state.

/home/freebsd (src) is UFS+SUJ.
/usr/obj is UFS+SU.
/tmp/build.log is tmpfs.

Both UFS file systems are on ada0:

ada0 at ata2 bus 0 scbus2 target 0 lun 0
ada0: WDC WD2502ABYS-18B7A0 02.03B05 ATA-8 SATA 2.x device
ata2: ATA channel at channel 0 on atapci0
atapci0: Intel 5 Series/3400 Series PCH SATA300 controller

CPU: Intel(R) Xeon(R) CPU   X3430  @ 2.40GHz (2394.04-MHz
K8-class CPU)
real memory  = 8589934592 (8192 MB)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s)

FreeBSD 9.1-RELEASE-p5 #0 r+94f2ad5: Tue Aug  6 09:40:22 CDT 2013
root@srv5:/usr/obj/home/freebsd/sys/GENERIC  amd64

/boot/loader.conf contains:

console=comconsole vidconsole
comconsole_speed=115200
comconsole_port=0x2f8

/etc/sysctl.conf is empty.

I'll update to releng/9.2 and try again.

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

Re: unexpected idprio 31 behavior on 9.2-BETA2 and 9.2-RC1

[Eric van Gyzen]

On 08/06/2013 10:31, Eric van Gyzen wrote:
 On 08/05/2013 16:15, Dave Mischler wrote:
 I have an i5-2500 machine 8GB RAM now running 9.2-RC1 amd64 with the
 GENERIC kernel. Today, while still running 9.2-BETA2, I updated my
 source tree and started building world with idprio 31 and I looked back
 a while later and all the CPU cores and disk were essentially idle, and
 hardly any progress had been made on the build. I stopped and restarted
 the build without the idle priority setting and it ran fine. Anybody
 else seen any of this? Anybody know about any fairly recent changes that
 might account for it?

 I did a rm -rf /usr/src /usr/obj and loaded a new source tree before
 going to RC1.  I still see odd behavior at RC1.  Sometimes it works just
 like it should (i.e. compute bound processes use most/all of the
 available CPU time), but a lot of the time both the CPU and disk are
 idle (e.g. CPU 97.8% idle, disk 1% busy per systat).  I don't think I
 ever saw this behavior before while running make buildworld -j4.  Can
 anyone else confirm/rebut my findings?  Thanks.
 I can confirm your findings, on 9.1-RELEASE-p5 amd64 GENERIC.

 I ran

 $ idprio 31 make buildworld buildkernel  /tmp/build.log 21 
 /dev/null 

 on an otherwise idle amd64 system with 4 CPUs.  The first command in the
 build.log file:

 rm -rf /usr/obj/home/freebsd/tmp

 took over three minutes.  It should have taken about three /seconds/.

 uptime reported a load average of around 1.00.
 top showed no threads (user or kernel) using CPU.
 iostat showed an average of less than 20 tps on ada0.
 rm was usually in the RUN state.

 /home/freebsd (src) is UFS+SUJ.
 /usr/obj is UFS+SU.
 /tmp/build.log is tmpfs.

 Both UFS file systems are on ada0:

 ada0 at ata2 bus 0 scbus2 target 0 lun 0
 ada0: WDC WD2502ABYS-18B7A0 02.03B05 ATA-8 SATA 2.x device
 ata2: ATA channel at channel 0 on atapci0
 atapci0: Intel 5 Series/3400 Series PCH SATA300 controller

 CPU: Intel(R) Xeon(R) CPU   X3430  @ 2.40GHz (2394.04-MHz
 K8-class CPU)
 real memory  = 8589934592 (8192 MB)
 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
 FreeBSD/SMP: 1 package(s) x 4 core(s)

 FreeBSD 9.1-RELEASE-p5 #0 r+94f2ad5: Tue Aug  6 09:40:22 CDT 2013
 root@srv5:/usr/obj/home/freebsd/sys/GENERIC  amd64

 /boot/loader.conf contains:

 console=comconsole vidconsole
 comconsole_speed=115200
 comconsole_port=0x2f8

 /etc/sysctl.conf is empty.

 I'll update to releng/9.2 and try again.

I see more-or-less the same behavior on 9.2-RC1 (r253912).  It seems to
be faster than 9.1, but it's still much slower than I would expect.

idprio 30 is much, much faster than 31.  It's about as fast as I would
expect (for this idle machine).  So, the problem seems to affect only
idprio 31.  (Off-by-one / fencepost problem?)

CPU-bound processes, such as c++, seem to run at the normal speeds, so
the problem seems to affect system- or I/O-bound work.

Can anyone try this on a 9.0-RELEASE system?

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

[patch] IPMI KCS can drop the lock while servicing a request

[Eric van Gyzen]

At work, we discovered that our application's IPMI thread would often 
use a lot of CPU time.  The KCS thread uses DELAY to wait for the BMC, 
so it can run without sleeping for a long time with a slow BMC.  It 
also holds the ipmi_softc.ipmi_lock during this time.  When using 
adaptive mutexes, an application thread that wants to operate on the 
ipmi_pending_requests list will also spin during this same time.


We see no reason that the KCS thread needs to hold the lock while 
servicing a request.  We've been running with the attached patch for a 
few months, with no ill effects.


Eric
diff --git a/sys/dev/ipmi/ipmi_kcs.c b/sys/dev/ipmi/ipmi_kcs.c
index 1ca3298..868570d 100644
--- a/sys/dev/ipmi/ipmi_kcs.c
+++ b/sys/dev/ipmi/ipmi_kcs.c
@@ -456,9 +456,11 @@ kcs_loop(void *arg)
 
 	IPMI_LOCK(sc);
 	while ((req = ipmi_dequeue_request(sc)) != NULL) {
+		IPMI_UNLOCK(sc);
 		ok = 0;
 		for (i = 0; i  3  !ok; i++)
 			ok = kcs_polled_request(sc, req);
+		IPMI_LOCK(sc);
 		if (ok)
 			req-ir_error = 0;
 		else
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: mfi(4) IO performance regression, post 8.1

[Eric van Gyzen]

On 07/17/12 15:39, Steve McCoy wrote:

On 7/13/12 9:39 AM, John Baldwin wrote:

On Thursday, July 12, 2012 11:47:28 pm Steve McCoy wrote:

On 7/12/12 4:34 PM, Steve McCoy wrote:

John Baldwin wrote:


Barring that, can you do a binary search of kernels from stable/8
between 8.1
and 8.2 on an 8.1 world to see which commit caused the change in write
performance?



Hi John, I'm working with Charles to narrow this down.

Looks like revision 212229 is the culprit, or at least around the same
time to it, if this change isn't what slowed things down. The change to
sys/kern/vfs_bio.c modifies some synchronization in dev_strategy():



Actually, hold that thought. I had a hunch that I wasn't thorough
enough, so I decided to try 212228 — the performance is the same as with
212229, so vfs_bio seems to be out of the picture. I'm going to binary
search between 209459 and 212229, and see what I find.


Ok. Please let me know what you find. Thanks!



Alright, I've finally narrowed it down to r209897, which only affects
acpi_cpu_idle():

--- stable/8/sys/dev/acpica/acpi_cpu.c 2010/06/23 17:04:42 209471
+++ stable/8/sys/dev/acpica/acpi_cpu.c 2010/07/11 11:58:46 209897
@@ -930,12 +930,16 @@

/*
* Execute HLT (or equivalent) and wait for an interrupt. We can't
- * calculate the time spent in C1 since the place we wake up is an
- * ISR. Assume we slept half of quantum and return.
+ * precisely calculate the time spent in C1 since the place we wake up
+ * is an ISR. Assume we slept no more then half of quantum.
*/
if (cx_next-type == ACPI_STATE_C1) {
- sc-cpu_prev_sleep = (sc-cpu_prev_sleep * 3 + 50 / hz) / 4;
+ AcpiHwRead(start_time, AcpiGbl_FADT.XPmTimerBlock);
acpi_cpu_c1();
+ AcpiHwRead(end_time, AcpiGbl_FADT.XPmTimerBlock);
+ end_time = acpi_TimerDelta(end_time, start_time);
+ sc-cpu_prev_sleep = (sc-cpu_prev_sleep * 3 +
+ min(PM_USEC(end_time), 50 / hz)) / 4;
return;
}

My current guess is that AcpiHwRead() is a problem on our hardware. It's
an isolated change and, to my desperate eyes, the commit message implies
that it isn't critical — Do you think we could buy ourselves some time
by pulling it out of our version of the kernel? Or is this essential for
correctness? Any thoughts are appreciated, thanks!


You might simply try a different idle function.  See these sysctls:

machdep.idle: acpi
machdep.idle_available: spin, mwait, mwait_hlt, hlt, acpi,

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

Re: ath(4) irq and taskq cpu usage

[Eric van Gyzen]

Sam Leffler wrote:

Eric van Gyzen wrote:

The irq and taskq for my ath(4) card often use excessive amounts of CPU
time, even when my network is idle.  They are often above 10% and 15%,
respectively; occasionally, they are as high as 27% and 44%.

The system is an AMD Athlon64 2800+ running FreeBSD 6.2-RELEASE i386
with a custom kernel including the wlan_* stuff, ath, ath_hal, and
ath_rate_sample.  It is a station using WPA2-PSK with AES-CCMP.  The
access point is also a FreeBSD machine with an ath(4) card.

During periods of high CPU usage, the

rx failed 'cuz of PHY err
OFDM timing

fields of the athstats output are increasing rather quickly.  For
example, while CPU usage was 25% and 46%, the OFDM timing field was
increasing by 43,000 per second.

Can anyone explain this?  Is it a sign of failing hardware?


It means you're seeing lots of noise in the environment.  The numbers
you cite are way too high (43K/sec is crazy) and the %cpu times see too
high for your processor but that's hard to evaluate.  You don't indicate
what your h/w is (mac+phy) revs but presumably it's old enough that PHY
errors are not counted in h/w but instead sent to the host as little
packets that must be processed.  If you actually use the radio you'll
see the error counts go down because the radio will be busy doing useful
work.


ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
ath0: Atheros 5212 mem 0xea10-0xea10 irq 17 at device 9.0 on pci0
ath0: Ethernet address: 00:11:95:91:32:f4
ath0: mac 7.9 phy 4.5 radio 5.6

I also have a P3 1.0 GHz laptop running FreeBSD 6.2 with a CardBus ath card 
with the same hardware revisions and configuration.  When ath CPU usage is 
high on the desktop, it's perfectly normal on the laptop (below 2%), even 
when the two are only a meter apart.  The CPU usage on the AP is also normal.


The desktop and AP have D-Link DWL-G520 cards; the laptop has a Netgear WG511T.


High phy error rates can also be caused by things like faulty antenna
connections and/or radio overload (i.e. sta and ap being too close
and/or using high power radios).


I put a different antenna on the desktop, with no change.  The STA and AP 
are about ten meters apart.



I can add a knob to the driver to turn off this stuff but then you will
likely see degraded performance as the PHY errors are used to tune the
baseband when there is noise and/or when the case temperature changes
(this can significantly affect radio operation).


I wouldn't ask you to do that, but thanks for offering.

I should also mention that the desktop occasionally reboots spontaneously, 
as if I had hit the reset button.  In particular, I wonder if the ath card 
is flaking out.  The wild CPU usage and spontaneous resets /might/ have 
started around the same time, but I might be hallucinating.


Thanks for your help and education...and for writing the driver in the first 
place.


Eric
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

ath(4) irq and taskq cpu usage

[Eric van Gyzen]

The irq and taskq for my ath(4) card often use excessive amounts of CPU 
time, even when my network is idle.  They are often above 10% and 15%, 
respectively; occasionally, they are as high as 27% and 44%.


The system is an AMD Athlon64 2800+ running FreeBSD 6.2-RELEASE i386 with a 
custom kernel including the wlan_* stuff, ath, ath_hal, and ath_rate_sample. 
 It is a station using WPA2-PSK with AES-CCMP.  The access point is also a 
FreeBSD machine with an ath(4) card.


During periods of high CPU usage, the

rx failed 'cuz of PHY err
OFDM timing

fields of the athstats output are increasing rather quickly.  For example, 
while CPU usage was 25% and 46%, the OFDM timing field was increasing by 
43,000 per second.


Can anyone explain this?  Is it a sign of failing hardware?

Thanks,

Eric
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

panic: sleeping thread

[Eric van Gyzen]

I saw a recent thread about a sleeping thread panic.
I submitted kern/102654 for one on 6.1-RELEASE-p1:

http://www.freebsd.org/cgi/query-pr.cgi?pr=102654

I'll gladly help you debug it.

Eric
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

panic sbdrop on 6.0-RELEASE-p4 i386

[Eric van Gyzen]

I recently had two sbdrop panics on 6.0-RELEASE-p4 i386.  Following 
are the stack traces and the kernel configuration.


Of course, I still have the crash dumps, and I'll gladly help anyone who 
wants more informaion.


--Eric




$ kgdb kernel.debug /var/crash/vmcore-panic-sbdrop-2006-03-09
GNU gdb 6.1.1 [FreeBSD]
[...]

Unread portion of the kernel message buffer:

[not ascii; here is a hexdump]

 c1  20 33 70 c0 00 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
29 00 00 00 00 00 00 00  00 90 02 00 00 00 00 00
00 00 00 00 6c 0b 05 c1  00 00 00 00 09 00 01 00
00 00 00 00 00 00 00 00  00 00 00 00 88 14 05 c1
30 33 70 c0 00 00 00 00  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  2a 00 00 00 00 00 00 00
00 a0 02 00 00 00 00 00  00 00 00 00 b4 0b 05 c1
00 00 00 00 0d 0a 00 01  00 00 00 00 00 00 00 00
00 00 00 00 00 d0 14 05  c1 40 33 70 c0 18 0c 05
c1 90 a3 4b c1 88 a3 4b  c1 00 00 00 00 6c 7f 4f
c1 f8 15 00 00 00 00 00  00 00 b0 02 00 00 00 00

#0  doadump () at pcpu.h:165
165 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) bt f
#0  doadump () at pcpu.h:165
No locals.
#1  0xc04fae3e in boot (howto=260) at 
/freebsd/src/sys/kern/kern_shutdown.c:399

first_buf_printf = 1
#2  0xc04fb104 in panic (fmt=0xc069ed40 sbdrop)
at /freebsd/src/sys/kern/kern_shutdown.c:555
td = (struct thread *) 0xc190e480
bootopt = 260
newpanic = 1
ap = 0xc190e480 
buf = sbdrop, '\0' repeats 249 times
#3  0xc05378b8 in sbdrop_locked (sb=0xcf603b50, len=940)
at /freebsd/src/sys/kern/uipc_socket2.c:1157
m = (struct mbuf *) 0x0
next = (struct mbuf *) 0x0
#4  0xc05377ce in sbflush_locked (sb=0xcf603b50)
at /freebsd/src/sys/kern/uipc_socket2.c:1124
No locals.
#5  0xc0536d49 in sbrelease_locked (sb=0xcf603b50, so=0x0)
at /freebsd/src/sys/kern/uipc_socket2.c:559
No locals.
#6  0xc0536db1 in sbrelease (sb=0xcf603b50, so=0xc19c2c84)
at /freebsd/src/sys/kern/uipc_socket2.c:572
No locals.
#7  0xc0534921 in sorflush (so=0xc19c2c84)
at /freebsd/src/sys/kern/uipc_socket.c:1480
sb = (struct sockbuf *) 0xc19c2cd4
pr = (struct protosw *) 0xc06d46a0
asb = {sb_sel = {si_thrlist = {tqe_next = 0x0, tqe_prev = 0x0},
  si_thread = 0x0, si_note = {kl_list = {slh_first = 0x0},
  kl_lock = 0,
  kl_unlock = 0, kl_locked = 0, kl_lockarg = 0x0}, si_flags = 0},
  sb_mtx = {mtx_object = {lo_class = 0xc06cf004,
  lo_name = 0xc069ecad so_rcv, lo_type = 0xc069ecad so_rcv,
  lo_flags = 196608, lo_list = {tqe_next = 0x0, tqe_prev = 0x0},
  lo_witness = 0x0}, mtx_lock = 3247498368, mtx_recurse = 0},
  sb_state = 0, sb_mb = 0xc29af800, sb_mbtail = 0xc29af800,
  sb_lastrecord = 0xc29af800, sb_cc = 940, sb_hiwat = 8192,
  sb_mbcnt = 2048, sb_mbmax = 65536, sb_ctl = 0, sb_lowat = 1,
  sb_timeo = 0, sb_flags = 64}
#8  0xc0532cbb in sofree (so=0xc19c2c84)
at /freebsd/src/sys/kern/uipc_socket.c:406
head = (struct socket *) 0x0
#9  0xc0532fe9 in soclose (so=0xc19c2c84)
at /freebsd/src/sys/kern/uipc_socket.c:484
error = 0
#10 0xc0522e6b in soo_close (fp=0xc1eac870, td=0xc190e480)
at /freebsd/src/sys/kern/sys_socket.c:317
error = 0
so = (struct socket *) 0x0
#11 0xc04dc0d4 in fdrop_locked (fp=0xc1eac870, td=0xc190e480)
at file.h:289
error = 0
#12 0xc04dc025 in fdrop (fp=0xc1eac870, td=0xc190e480)
at /freebsd/src/sys/kern/kern_descrip.c:2101
No locals.
#13 0xc04da653 in closef (fp=0xc1eac870, td=0xc190e480)
at /freebsd/src/sys/kern/kern_descrip.c:1921
vp = (struct vnode *) 0xc1eac870
lf = {l_start = 4294967295, l_len = -4495592928909675680,
  l_pid = 0, l_type = -7040, l_whence = -15984}
fdtol = (struct filedesc_to_leader *) 0xcf603ca0
fdp = (struct filedesc *) 0xc2ce5200
#14 0xc04d7a81 in close (td=0xc190e480, uap=0x0)
at /freebsd/src/sys/kern/kern_descrip.c:1004
fdp = (struct filedesc *) 0xc2ce5200
fp = (struct file *) 0xc1eac870
fd = 1
error = -1047468928
holdleaders = 0
#15 0xc0662dbb in syscall (frame=
  {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 1,
   tf_esi = 134613344, tf_ebp = -1077941400, tf_isp = -815776412,
   tf_ebx = 134729728, tf_edx = 0, tf_ecx = 1, tf_eax = 6,
   tf_trapno = 22, tf_err = 2, tf_eip = 169785299, tf_cs = 51,
   tf_eflags = 642, tf_esp = -1077941428, tf_ss = 59})
at /freebsd/src/sys/i386/i386/trap.c:976
params = 0xbfbfeb50 Address 0xbfbfeb50 out of bounds
callp = (struct sysent *) 0xc06ca6e8
td = (struct thread *) 0xc190e480
p = (struct proc *) 0xc19c720c
orig_tf_eflags = 642
sticks = 4436
error = 0
narg = 1
args = {1, -815776464, -1067048045, 0, 0, 0, 4436, -1046711796}