Re: Need some help with ports and rebuilding the world

[Gary Jennejohn]

On Mon, 28 Mar 2016 08:47:35 +0300
Aleksander Alekseev  wrote:

> > What's the output of these commands?:
> > 
> > freebsd-version
> > uname -r
> > uname -a
> > grep "define __FreeBSD_version" /usr/include/sys/param.h
> >   
> 
> $ freebsd-version
> 10.2-RELEASE
> 
> $ uname -r
> 11.0-CURRENT
> 
> $ uname -a
> FreeBSD portege 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r297287: Sat Mar
> 26 12:36:04 MSK 2016 root@portege:/usr/obj/usr/src/head/sys/GENERIC
> amd64
> 
> $ grep "define __FreeBSD_version" \
>   /usr/include/sys/param.h
> 
> #define __FreeBSD_version 1002000 /* Master, propagated to newvers */
> 
> It used to be FreeBSD 10.2 but I rebuilded and reinstall kernel and
> world from CURRENT according to Handbook instructions. I have exact
> steps recorded in case it would help. I hope such way of upgrading
> FreeBSD is correct?
> 

Looks like your kernel is based on 11-CURRENT but your world is
still 10.2.

Try looking at /usr/src/sys/sys/param.h.  If that contains 1100xxx
then you probably have to make buildworld followed by make installworld.

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

Re: Need some help with ports and rebuilding the world

[Aleksander Alekseev]

> It used to be FreeBSD 10.2 but I rebuilded and reinstall kernel and
> world from CURRENT according to Handbook instructions. I have exact
> steps recorded in case it would help. I hope such way of upgrading
> FreeBSD is correct?

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

-- 
Best regards,
Aleksander Alekseev
http://eax.me/
___
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: SD card adapter doesn't working anymore

[Ruslan Makhmatkhanov]

Ian Lepore wrote on 03/28/16 05:29 AM:

[...]


I updated to r297281 with this quirk applied. Sadly, it doesn't
change
anything - controllers still not recognized. I also tried to boot
this
revision with disabled hw.sdhci.enable_msi=0, that I applied earlier.



I finally found some time today to give this stuff a try on my one x86
system that has an sdhci controller in it.  Unfortunately, everything
just works fine.  I tried with a GENERIC kernel that has those devices
compiled in, and I tried taking them out and loading sdhci_pci, mmc,
and mmcsd as modules, and everything just worked both ways.

The only thing I can think of now is to turn up the debugging levels.
  That's going to generate a lot of spewage, but if you paste/upload the
output somewhere I'll look through it.  So try setting:

   hw.sdhci.debug=3
   hw.mmc.debug=3

in either loader.conf or via sysctl before you kldload the modules.  If
the sdhci output is too trashed with interrupt info, maybe lower it to
2.

-- Ian


Ian, not much changed with setting this knobs in loader.conf except of 
showing the "REGISTER DUMP" table, that I already sent you in one of 
earlier responses. Here is the full dmesg: https://dpaste.de/GeaT/raw


Also nothing is showing in messages/console upon plugging an SD card. 
Maybe I should enable some debug in kernel to make it show anything? 
Here is my kern conf: https://dpaste.de/0v9k/raw It's mostly generic, 
but with debug bits disabled.


Mine mmc/sdhci stuff is compiled in and shown in kldstat output:
[rm@smsh-zfs ~]> kldstat -v | grep mmc
238 sdhci_pci/mmc
187 mmc/mmcsd

--
Regards,
Ruslan

T.O.S. Of Reality
___
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"

Panic after update from r297313 -> r297348

[David Wolfskill]

Unfortunately, the serial console only seemed to be echoing characters
in quasi-random spurts, yielding such things as:

...
r() at lcpu_initcpu_initclocks_bsp+0x37f/frame 0x820dbb40
initclocks() at initclocks+0x20/frame 0x820dbb50
mi_start+0x2c

Tracing  td 0xffc_et_start+0x2d9/frame 0x820dbaa0
loadtimer() at lrame 0xf configtsp() at clocks_bsp+0x37f/frame 
0x820dbb40
initclocks() at initclocks+0x20/
Tracing pid 0 tid 10 td 0x81d11200
lapic_et_start()c_et_start+0x2d9/frame 0x820dbaa0
+0x2cimeoadtimer+0x102/frame 0xf20dbac0
db> 
pid 0 tid 10 td 0x81d11200
lapic_et_start() at lapic_et_start+0x2d9x820dbaa0
loadtimer() at loadtimer+0x102/frame 0x8imer+0x239/frame 
0x820dbb10
cpu_initsp() at f820dbb7pid 0 ti td 0x81_start()c_et_staf820dbaa0
r() at loadtimer+0x102/8
configtimer() atcpu_initxfffpid 0 
tif820dbaa0| |___ _ __ ___  ___ | |_) | (___ | |  |   ___| '__/ _ \/ _ \|  _ < 
\___ \| |  | |dtimer() at loadtimer+0x102/frame 0x8 0x820dbb10
c| |   | | |  __/  __/| |_) |) | |__| |
b| |   | |  \___|\|200
configtimer() at configtimer+0x239/frame 0x820dbb10
cpu_initclocks_bcpu_initsp+0x37f/frame 0f820dbb40
initclocks() at initclocks+0x20/frame 0x820dbb50
mi_startup() at mi_startup+0x118/frame 0
Tracing d 10lapic_et_start() at lapic_et_start+0x2d9sp+0x37f+0x2c
db> 0
 0x820dbsp+0x37ff820dbb4ks() at 
mi_startup() at up+0x118/frame 0x820dbb70
btext() at btext+0x2c
db> bd 10+0x102/frame 0xfcpu_initframe 0x+0x2c
pic[K]ernel (1 of 2)
r|m 6.bConfigure Boot [O]ptions...
 H| vpanic+0x182/frame 0x820db4a0+
db_commaf0.-- 
sp+0x37f0/frame 0x820db6kdb_trapf820d.---..__   
   _ _   | |  _ \ / |  __ \ 
bte   
Uptime: 1s 
-c0+0x4db8+0x15eef8+0x8+0x]+-y+:.  `:`


at which point I had already (semi-blindly) tried "panic", so I
tried "reset", then I was able to escape to the loader, unload the
new kernel, boot the previous one, move the various kernel*
difrectories around in /boot, then reboot again to old kernel:

FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #2028  
r297313M/297313:1100104: Sun Mar 27 06:27:24 PDT 2016 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

I'm still building on my laptop; while I hope I don't have the character-
dropping issues there (as I have no serial console on it), I also don't
have much of a way to communicate what it displays if it (also) panics.

Apparently my attempt at "panic" didn't get a crash dump.. :-(

Any suggestions for diagnosing this?

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Panic after update from r297313 -> r297348

[Konstantin Belousov]

On Mon, Mar 28, 2016 at 05:36:13AM -0700, David Wolfskill wrote:
> Unfortunately, the serial console only seemed to be echoing characters
> in quasi-random spurts, yielding such things as:
> 
> ...
> r() at lcpu_initcpu_initclocks_bsp+0x37f/frame 0x820dbb40
> initclocks() at initclocks+0x20/frame 0x820dbb50
> mi_start+0x2c
> 
> Tracing  td 0xffc_et_start+0x2d9/frame 0x820dbaa0
> loadtimer() at lrame 0xf configtsp() at clocks_bsp+0x37f/frame 
> 0x820dbb40
> initclocks() at initclocks+0x20/
> Tracing pid 0 tid 10 td 0x81d11200
> lapic_et_start()c_et_start+0x2d9/frame 0x820dbaa0
> +0x2cimeoadtimer+0x102/frame 0xf20dbac0
> db> 
> pid 0 tid 10 td 0x81d11200
> lapic_et_start() at lapic_et_start+0x2d9x820dbaa0
> loadtimer() at loadtimer+0x102/frame 0x8imer+0x239/frame 
> 0x820dbb10
> cpu_initsp() at f820dbb7pid 0 ti td 0x81_start()c_et_staf820dbaa0
> r() at loadtimer+0x102/8
> configtimer() atcpu_initxfffpid 0 
> tif820dbaa0| |___ _ __ ___  ___ | |_) | (___ | |  |   ___| '__/ _ \/ _ \|  _ 
> < \___ \| |  | |dtimer() at loadtimer+0x102/frame 0x8 
> 0x820dbb10
> c| |   | | |  __/  __/| |_) |) | |__| |
> b| |   | |  \___|\|200
> configtimer() at configtimer+0x239/frame 0x820dbb10
> cpu_initclocks_bcpu_initsp+0x37f/frame 0f820dbb40
> initclocks() at initclocks+0x20/frame 0x820dbb50
> mi_startup() at mi_startup+0x118/frame 0
> Tracing d 10lapic_et_start() at lapic_et_start+0x2d9sp+0x37f+0x2c
> db> 0
>  0x820dbsp+0x37ff820dbb4ks() at 
> mi_startup() at up+0x118/frame 0x820dbb70
> btext() at btext+0x2c
> db> bd 10+0x102/frame 0xfcpu_initframe 0x+0x2c
> pic[K]ernel (1 of 2)
> r|m 6.bConfigure Boot [O]ptions...
>  H| vpanic+0x182/frame 0x820db4a0+
> db_commaf0.-- 
> sp+0x37f0/frame 0x820db6kdb_trapf820d.---..__ 
>      _ _   | |  _ \ / |  __ \ 
> bte   
> Uptime: 1s
>  -c0+0x4db8+0x15eef8+0x8+0x]+-y+:.  `:`
> 
> 
> at which point I had already (semi-blindly) tried "panic", so I
> tried "reset", then I was able to escape to the loader, unload the
> new kernel, boot the previous one, move the various kernel*
> difrectories around in /boot, then reboot again to old kernel:
> 
> FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #2028  
> r297313M/297313:1100104: Sun Mar 27 06:27:24 PDT 2016 
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
> 
> I'm still building on my laptop; while I hope I don't have the character-
> dropping issues there (as I have no serial console on it), I also don't
> have much of a way to communicate what it displays if it (also) panics.
> 
> Apparently my attempt at "panic" didn't get a crash dump.. :-(
> 
> Any suggestions for diagnosing this?
> 

Show me verbose dmesg of the running kernel.
Also, does anything change with the faulting kernel if you set
hw.lapic_tsc_deadline to 0 in loader ?
___
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: Panic after update from r297313 -> r297348

[David Wolfskill]

On Mon, Mar 28, 2016 at 03:57:01PM +0300, Konstantin Belousov wrote:
> ...
> Also, does anything change with the faulting kernel if you set
> hw.lapic_tsc_deadline to 0 in loader ?

Yes: the machine then boots succesfully:

freebeast(11.0-C)[1] uname -a
FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #2029  
r297348M/297348:1100104: Mon Mar 28 04:55:00 PDT 2016 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
freebeast(11.0-C)[2] 


This was after appending the line:

hw.lapic_tsc_deadline="0"

to /boot/loader.conf.

(I have not -- yet, at least -- tried that with my laptop.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Need some help with ports and rebuilding the world

[Aleksander Alekseev]

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

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

http://lpaste.net/948188758727983104

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

Thoughts?

-- 
Best regards,
Aleksander Alekseev
http://eax.me/
___
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: SD card adapter doesn't working anymore

[Ian Lepore]

On Mon, 2016-03-28 at 12:33 +0300, Ruslan Makhmatkhanov wrote:
> Ian Lepore wrote on 03/28/16 05:29 AM:
> 
> [...]
> 
> > > I updated to r297281 with this quirk applied. Sadly, it doesn't
> > > change
> > > anything - controllers still not recognized. I also tried to boot
> > > this
> > > revision with disabled hw.sdhci.enable_msi=0, that I applied
> > > earlier.
> > > 
> > 
> > I finally found some time today to give this stuff a try on my one
> > x86
> > system that has an sdhci controller in it.  Unfortunately,
> > everything
> > just works fine.  I tried with a GENERIC kernel that has those
> > devices
> > compiled in, and I tried taking them out and loading sdhci_pci,
> > mmc,
> > and mmcsd as modules, and everything just worked both ways.
> > 
> > The only thing I can think of now is to turn up the debugging
> > levels.
> >   That's going to generate a lot of spewage, but if you
> > paste/upload the
> > output somewhere I'll look through it.  So try setting:
> > 
> >hw.sdhci.debug=3
> >hw.mmc.debug=3
> > 
> > in either loader.conf or via sysctl before you kldload the modules.
> >   If
> > the sdhci output is too trashed with interrupt info, maybe lower it
> > to
> > 2.
> > 
> > -- Ian
> 
> Ian, not much changed with setting this knobs in loader.conf except
> of 
> showing the "REGISTER DUMP" table, that I already sent you in one of 
> earlier responses. Here is the full dmesg: https://dpaste.de/GeaT/raw
> 
> Also nothing is showing in messages/console upon plugging an SD card.
> Maybe I should enable some debug in kernel to make it show anything? 
> Here is my kern conf: https://dpaste.de/0v9k/raw It's mostly generic,
> but with debug bits disabled.
> 
> Mine mmc/sdhci stuff is compiled in and shown in kldstat output:
> [rm@smsh-zfs ~]> kldstat -v | grep mmc
>   238 sdhci_pci/mmc
>   187 mmc/mmcsd
> 

Wow, there's just nothing to work with in that output.  I think the
increased debuging didn't output anything because nothing is happening,
and that's consistant with the value in the Present State register when
the driver attaches, which says that no card is inserted.  (It says
that in several ways... when a card is in, half a dozen of those bits
should be non-zero.)

It makes me think the controller isn't powered up, or is in some
suspend mode or something.  But that would be at the pci bus level, not
something the driver is in control of.  I had a problem like that
initially on my FitPc2 x86 board that has sdhci on it, but the problem
went away with a bios update.

-- Ian

___
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: SD card adapter doesn't working anymore

[Ruslan Makhmatkhanov]

Ian Lepore wrote on 03/28/16 06:38 PM:

On Mon, 2016-03-28 at 12:33 +0300, Ruslan Makhmatkhanov wrote:

Ian Lepore wrote on 03/28/16 05:29 AM:

[...]


I updated to r297281 with this quirk applied. Sadly, it doesn't
change
anything - controllers still not recognized. I also tried to boot
this
revision with disabled hw.sdhci.enable_msi=0, that I applied
earlier.



I finally found some time today to give this stuff a try on my one
x86
system that has an sdhci controller in it.  Unfortunately,
everything
just works fine.  I tried with a GENERIC kernel that has those
devices
compiled in, and I tried taking them out and loading sdhci_pci,
mmc,
and mmcsd as modules, and everything just worked both ways.

The only thing I can think of now is to turn up the debugging
levels.
   That's going to generate a lot of spewage, but if you
paste/upload the
output somewhere I'll look through it.  So try setting:

hw.sdhci.debug=3
hw.mmc.debug=3

in either loader.conf or via sysctl before you kldload the modules.
   If
the sdhci output is too trashed with interrupt info, maybe lower it
to
2.

-- Ian


Ian, not much changed with setting this knobs in loader.conf except
of
showing the "REGISTER DUMP" table, that I already sent you in one of
earlier responses. Here is the full dmesg: https://dpaste.de/GeaT/raw

Also nothing is showing in messages/console upon plugging an SD card.
Maybe I should enable some debug in kernel to make it show anything?
Here is my kern conf: https://dpaste.de/0v9k/raw It's mostly generic,
but with debug bits disabled.

Mine mmc/sdhci stuff is compiled in and shown in kldstat output:
[rm@smsh-zfs ~]> kldstat -v | grep mmc
238 sdhci_pci/mmc
187 mmc/mmcsd



Wow, there's just nothing to work with in that output.  I think the
increased debuging didn't output anything because nothing is happening,
and that's consistant with the value in the Present State register when
the driver attaches, which says that no card is inserted.  (It says
that in several ways... when a card is in, half a dozen of those bits
should be non-zero.)

It makes me think the controller isn't powered up, or is in some
suspend mode or something.  But that would be at the pci bus level, not
something the driver is in control of.  I had a problem like that
initially on my FitPc2 x86 board that has sdhci on it, but the problem
went away with a bios update.

-- Ian


Ok, I'll try to do something about that. Just want to tell, that some 
time ago, after this controller stopped to work in -current, I had dual 
boot system with windows. And when I was needed to burn some SD, I just 
booted to windows and successfully write SD.


I have a latest firmware for my laptop installed, so the only thing I 
can try is to boot some old FreeBSD versions to see if it will work with 
them, because this firmware can't be downgraded as far I know.


--
Regards,
Ruslan

T.O.S. Of Reality
___
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: sr-iov issues, reset_hw() failed with error -100

[Ultima]

Recently upgraded to r297351, once running iovctl -C -f /etc/iovctl.conf
everything appears to work as it should. The main network interface ramains
connected and pinging works fine.

iovctl.conf
PF {
device : ix1;
num_vfs : 31;
}

DEFAULT {
passthrough : true;
}
VF-0 {
passthrough : false;
}
VF-1 {
passthrough : false;
}

Once vf's have been initialized, I have found none-passthrough vf's are
unusable.

# devctl attach pci0:129:0:129
devctl: Failed to attach pci0:129:0:129: Input/output error

The dmesg spits out the same error as before, so it appears that the errors
I was mentioning before is actually the none-passthrough vf's attempting to
attach, but fails.

/var/log/messages:
ixv0:  at device 0.131 on pci12
ixv0: Using MSIX interrupts with 2 vectors
ixv0: ixgbe_reset_hw() failed with error -100
device_attach: ixv0 attach returned 5
ixv0:  at device 0.129 on pci12
ixv0: Using MSIX interrupts with 2 vectors
ixv0: ixgbe_reset_hw() failed with error -100
device_attach: ixv0 attach returned 5

On Wed, Mar 9, 2016 at 5:36 PM, Ultima  wrote:

> I have been interested in this when I first read about it in 2012. =]
>
> Can this be done in loader.conf? I have vmm_load="YES"
>
> I'm not sure if the vf's are usable, I have not actually tested the vf's.
> The parent ix1 still shows no response.
>
> kldunload vmm
>
> kenv hw.vmm.force_iommu=1
>
> kldload vmm
>
> iovctl -Cf /etc/iovctl.conf
>
> The same error messages appear, I currently on hmm i'm not sure, I
> upgraded with git and it doesn't show rev(last time I use git for
> source?) 8b372d1(master)
>
> On Wed, Mar 9, 2016 at 5:00 PM, Eric Joyner  wrote:
>
>> I don't know if you're still interested in this, but did you do "kenv
>> hw.vmm.force_iommu=1" before loading the vmm module? I think that might be
>> necessary.
>>
>> On Wed, Feb 24, 2016 at 5:12 PM Ultima  wrote:
>>
>>>  Yeah, still getting the -100 error, I do have sendmail disabled. I just
>>> tested with sendmail up and running then add the VF's and it still shows
>>> the error message.
>>>
>>> On Wed, Feb 24, 2016 at 8:04 PM, Eric Joyner  wrote:
>>>
 Are you still getting the -100 errors when trying to load the VF driver?

 I've tried SR-IOV on a system here, and I can confirm that traffic
 stops passing on the PF interface when you create a VF interface. That
 didn't used to happen, so I'm investigating why that is right now.

 On Wed, Feb 24, 2016 at 8:09 AM Ultima  wrote:

>  Decided to do some more tests, I actually have a second board with
> sr-iov
> capabilities that I used for awhile with vmware esxi. I decided to test
> this out and unfortunately it won't activate, it is giving the no space
> left on device error message. I double checked bios and all VT-d
> related
> options are enabled and have hw.ix.num_queues="4" in
> /boot/loader.conf. Is
> there anything else that may need to be set? .(It did work on vmware)
>
>  For my second test, I moved the X540-AT1 to the board with the
> X540-AT2.
> It functioned with the same issues as the AT2 tho.
>
>
> I don't think I listed the motherboards in question yet so ill list
> them
> now.
>
> S1200BTLRM -
>
> http://ark.intel.com/products/69633/Intel-Server-Board-S1200BTLRM?q=S1200BTLRM
> MD80-TM0
> 
> - http://b2b.gigabyte.com/products/product-page.aspx?pid=5146#ov
>
> I'm not sure if it will be of any help tho.
>
> Ultima
> ___
> 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: CURRENT slow and shaky network stability

[Don Lewis]

On 28 Mar, O. Hartmann wrote:
> Am Sat, 26 Mar 2016 14:26:45 -0700 (PDT)
> Don Lewis  schrieb:
> 
>> On 26 Mar, Michael Butler wrote:
>> > -current is not great for interactive use at all. The strategy of
>> > pre-emptively dropping idle processes to swap is hurting .. big time.
>> > 
>> > Compare inactive memory to swap in this example ..
>> > 
>> > 110 processes: 1 running, 108 sleeping, 1 zombie
>> > CPU:  1.2% user,  0.0% nice,  4.3% system,  0.0% interrupt, 94.5% idle
>> > Mem: 474M Active, 1609M Inact, 764M Wired, 281M Buf, 119M Free
>> > Swap: 4096M Total, 917M Used, 3178M Free, 22% Inuse
>> > 
>> >   PID USERNAME   THR PRI NICE   SIZERES STATE   C   TIMEWCPU
>> > COMMAND
>> >  1819 imb  1  280   213M 11284K select  1 147:44   5.97%
>> > gkrellm
>> > 59238 imb 43  200   980M   424M select  0  10:07   1.92%
>> > firefox
>> > 
>> >  .. it shouldn't start randomly swapping out processes because they're
>> > used infrequently when there's more than enough RAM to spare ..  
>> 
>> I don't know what changed, and probably something can use some tweaking,
>> but paging out idle processes isn't always the wrong thing to do.  For
>> instance if I'm using poudriere to build a bunch of packages and its
>> heavy use of tmpfs is pushing the machine into many GB of swap usage, I
>> don't want interactive use like:
>>  vi foo.c
>>  cc foo.c
>>  vi foo.c
>> to suffer because vi and cc have to be read in from a busy hard drive
>> each time while unused console getty and idle sshd processes in a bunch
>> of jails are still hanging on to memory even though they haven't
>> executed any instructions since shortly after the machine was booted
>> weeks ago.
>> 
>> > It also shows up when trying to reboot .. on all of my gear, 90 seconds
>> > of "fail-safe" time-out is no longer enough when a good proportion of
>> > daemons have been dropped onto swap and must be brought back in to flush
>> > their data segments :-(  
>> 
>> That's a different and known problem.  See:
>> 
> 
> CURRENT has rendered unusable and faulty. Updating ports for poudriere ends 
> up in this
> error/broken pipe from remote console:
> 
>  [~] poudriere ports -u -p head
> [00:00:00] >> Updating portstree "head"
> [00:00:00] >> Updating the ports tree... done
> root@gate [~] Fssh_packet_write_wait: Connection to 192.168.250.111 port 22: 
> Broken pipe
> 
> 
> Although not under load, several processes over time gets idled/paged out - 
> and they
> never recover, the connection is then sabott, the whole thing unusable :-(

I'm definitely not seeing that here.  This is getting close to the end
of a big poudriere run:

last pid: 82549;  load averages: 20.05, 20.72, 23.51up 5+12:34:14  12:51:55
144 processes: 20 running, 109 sleeping, 15 stopped
CPU: 85.3% user,  0.0% nice, 14.7% system,  0.0% interrupt,  0.0% idle
Mem: 1082M Active, 19G Inact, 9718M Wired, 249M Buf, 1095M Free
ARC: 3841M Total, 2039M MFU, 642M MRU, 3395K Anon, 111M Header, 1044M Other
Swap: 40G Total, 9691M Used, 31G Free, 23% Inuse, 196K In

At the moment, openoffice-4, openoffice-devel, libreoffice, and chromium
are all being built and are using tmpfs for "wrkdir data localbase", so
there are many GB of data in tmpfs, which is the reason for the high
inact and swap usage.  I just hit the return key in an idle (for a
couple of hours) terminal window containing an ssh login session to the
same machine.  I got a fresh command prompt essentially instantaneously.
It couldn't have taken more than a couple hundred milliseconds to wake
up and page in the idle sshd and shell processes on the build server.

[a couple hours later, after poudriere is done and all tmpfs is gone]

last pid: 66089;  load averages:  0.13,  1.59,  4.61up 5+14:14:33  14:32:14
71 processes:  1 running, 55 sleeping, 15 stopped
CPU:  3.1% user,  0.0% nice,  0.0% system,  0.0% interrupt, 96.9% idle
Mem: 58M Active, 85M Inact, 12G Wired, 249M Buf, 19G Free
ARC: 6249M Total, 2792M MFU, 2246M MRU, 16K Anon, 133M Header, 1078M Other
Swap: 40G Total, 81M Used, 40G Free

[after tracking down and exiting all of those stopped processes]

last pid: 66103;  load averages:  0.20,  0.99,  3.80up 5+14:17:18  14:34:59
56 processes:  1 running, 55 sleeping
CPU:  0.0% user,  0.0% nice,  0.1% system,  0.1% interrupt, 99.9% idle
Mem: 57M Active, 88M Inact, 12G Wired, 249M Buf, 19G Free
ARC: 6251M Total, 2793M MFU, 2247M MRU, 16K Anon, 133M Header, 1078M Other
Swap: 40G Total, 63M Used, 40G Free

The biggest chunk of the 63 MB of swap appears to be nginx.  It's
process size is 29 MB, but it has zero resident.  It hasn't executed any
code since it was first started when I booted the system several days
ago.  Other consumers appear to be getty and sshd and syslogd in various
untouched jails.


I've seen reports that r296137 and r297267 show the ssh problem, but
this machine is in t

Re: Need some help with ports and rebuilding the world

[Gary Jennejohn]

On Mon, 28 Mar 2016 17:00:31 +0300
Aleksander Alekseev  wrote:

> > I think I realized what's going on. I probably rebuilded the world on
> > two different machines but forgot to do it on this one. I will
> > re-check this and report results a bit later.  
> 
> OK, here is a problem. I can't upgrade the world because of compile
> errors I mentioned before:
> 
> http://lpaste.net/948188758727983104
> 
> This issue reproduces with both CLang 3.6 and new CLang compiled
> manually from trunk (I created symlinks clang++-3.9 and clang-cpp-3.9
> to clang-3.9 and it solved my problem with CLang I mentioned before).
> 
> Thoughts?
> 

I see that you're using clang36 from ports.  Right now clang38 is
what's being used in 11-CURRENT.  I don't know whether it will
help, but you could try installing clang38 from ports.

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

Re: Need some help with ports and rebuilding the world

[Gary Jennejohn]

On Tue, 29 Mar 2016 00:42:09 +0200
Gary Jennejohn  wrote:

> On Mon, 28 Mar 2016 17:00:31 +0300
> Aleksander Alekseev  wrote:
> 
> > > I think I realized what's going on. I probably rebuilded the world on
> > > two different machines but forgot to do it on this one. I will
> > > re-check this and report results a bit later.
> > 
> > OK, here is a problem. I can't upgrade the world because of compile
> > errors I mentioned before:
> > 
> > http://lpaste.net/948188758727983104
> > 
> > This issue reproduces with both CLang 3.6 and new CLang compiled
> > manually from trunk (I created symlinks clang++-3.9 and clang-cpp-3.9
> > to clang-3.9 and it solved my problem with CLang I mentioned before).
> > 
> > Thoughts?
> >   
> 
> I see that you're using clang36 from ports.  Right now clang38 is
> what's being used in 11-CURRENT.  I don't know whether it will
> help, but you could try installing clang38 from ports.
> 

Oops, I see you already tried the latest clang.

Sorry, can't think of anything other than installing 11-CURRENT from
scratch.

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

Re: Need some help with ports and rebuilding the world

[Dimitry Andric]

On 28 Mar 2016, at 16:00, Aleksander Alekseev  wrote:
> 
>> I think I realized what's going on. I probably rebuilded the world on
>> two different machines but forgot to do it on this one. I will
>> re-check this and report results a bit later.
> 
> OK, here is a problem. I can't upgrade the world because of compile
> errors I mentioned before:
> 
> http://lpaste.net/948188758727983104
> 
> This issue reproduces with both CLang 3.6 and new CLang compiled
> manually from trunk (I created symlinks clang++-3.9 and clang-cpp-3.9
> to clang-3.9 and it solved my problem with CLang I mentioned before).
> 
> Thoughts?

Don't try to build world with ports clang, it's not yet supported (at
least not officially, and without jumping through some flaming hoops).

Just use the compiler in the base system.

If all that doesn't work, your system is likely hosed, and reinstalling
from scratch is probably the easiest way to get back up to speed.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: CURRENT r296381 panic in vn_sendfile (/usr/src/sys/kern/kern_sendfile.c:833)

[Gleb Smirnoff]

  Vitalij,

  here is latest version of the patch. If you already run the
previous one, no need to switch to this one, keep running as is.
The update covers only FreeBSD 4 and i386 compatibilties.

current@, a review is appreciated. The patch not only fixes a
recent bug, but also fixes a long standing problem that headers
were not checked against socket buffer size. One could push
unlimited data into sendfile() with headers. The patch also
pushes also compat code under ifdef, so it is cut away if
you aren't interested in COMPAT_FREEBSD4.

On Wed, Mar 23, 2016 at 04:59:25PM -0700, Gleb Smirnoff wrote:
T>   Vitalij,
T> 
T>   although the first patch should fixup the panic, can you please
T> instead run this one. And if it is possible, can you please
T> monitor this sysctl:
T> 
T> sysctl kern.ipc.sf_long_headers
T> 
T> 
T> -- 
T> Totus tuus, Glebius.

T> Index: sys/kern/kern_descrip.c
T> ===
T> --- sys/kern/kern_descrip.c  (revision 297217)
T> +++ sys/kern/kern_descrip.c  (working copy)
T> @@ -3958,7 +3958,7 @@ badfo_chown(struct file *fp, uid_t uid, gid_t gid,
T>  static int
T>  badfo_sendfile(struct file *fp, int sockfd, struct uio *hdr_uio,
T>  struct uio *trl_uio, off_t offset, size_t nbytes, off_t *sent, int 
flags,
T> -int kflags, struct thread *td)
T> +struct thread *td)
T>  {
T>  
T>  return (EBADF);
T> @@ -4044,7 +4044,7 @@ invfo_chown(struct file *fp, uid_t uid, gid_t gid,
T>  int
T>  invfo_sendfile(struct file *fp, int sockfd, struct uio *hdr_uio,
T>  struct uio *trl_uio, off_t offset, size_t nbytes, off_t *sent, int 
flags,
T> -int kflags, struct thread *td)
T> +struct thread *td)
T>  {
T>  
T>  return (EINVAL);
T> Index: sys/kern/kern_sendfile.c
T> ===
T> --- sys/kern/kern_sendfile.c (revision 297217)
T> +++ sys/kern/kern_sendfile.c (working copy)
T> @@ -95,6 +95,7 @@ struct sendfile_sync {
T>  };
T>  
T>  counter_u64_t sfstat[sizeof(struct sfstat) / sizeof(uint64_t)];
T> +static counter_u64_t sf_long_headers; /* QQQGL */
T>  
T>  static void
T>  sfstat_init(const void *unused)
T> @@ -102,6 +103,7 @@ sfstat_init(const void *unused)
T>  
T>  COUNTER_ARRAY_ALLOC(sfstat, sizeof(struct sfstat) / sizeof(uint64_t),
T>  M_WAITOK);
T> +sf_long_headers = counter_u64_alloc(M_WAITOK); /* QQQGL */
T>  }
T>  SYSINIT(sfstat, SI_SUB_MBUF, SI_ORDER_FIRST, sfstat_init, NULL);
T>  
T> @@ -117,6 +119,8 @@ sfstat_sysctl(SYSCTL_HANDLER_ARGS)
T>  }
T>  SYSCTL_PROC(_kern_ipc, OID_AUTO, sfstat, CTLTYPE_OPAQUE | CTLFLAG_RW,
T>  NULL, 0, sfstat_sysctl, "I", "sendfile statistics");
T> +SYSCTL_COUNTER_U64(_kern_ipc, OID_AUTO, sf_long_headers, CTLFLAG_RW,
T> +&sf_long_headers, "times headers did not fit into socket buffer");
T>  
T>  /*
T>   * Detach mapped page and release resources back to the system.  Called
T> @@ -516,7 +520,7 @@ sendfile_getsock(struct thread *td, int s, struct
T>  int
T>  vn_sendfile(struct file *fp, int sockfd, struct uio *hdr_uio,
T>  struct uio *trl_uio, off_t offset, size_t nbytes, off_t *sent, int 
flags,
T> -int kflags, struct thread *td)
T> +struct thread *td)
T>  {
T>  struct file *sock_fp;
T>  struct vnode *vp;
T> @@ -534,7 +538,7 @@ vn_sendfile(struct file *fp, int sockfd, struct ui
T>  so = NULL;
T>  m = mh = NULL;
T>  sfs = NULL;
T> -sbytes = 0;
T> +hdrlen = sbytes = 0;
T>  softerr = 0;
T>  
T>  error = sendfile_getobj(td, fp, &obj, &vp, &shmfd, &obj_size, &bsize);
T> @@ -560,26 +564,6 @@ vn_sendfile(struct file *fp, int sockfd, struct ui
T>  cv_init(&sfs->cv, "sendfile");
T>  }
T>  
T> -/* If headers are specified copy them into mbufs. */
T> -if (hdr_uio != NULL && hdr_uio->uio_resid > 0) {
T> -hdr_uio->uio_td = td;
T> -hdr_uio->uio_rw = UIO_WRITE;
T> -/*
T> - * In FBSD < 5.0 the nbytes to send also included
T> - * the header.  If compat is specified subtract the
T> - * header size from nbytes.
T> - */
T> -if (kflags & SFK_COMPAT) {
T> -if (nbytes > hdr_uio->uio_resid)
T> -nbytes -= hdr_uio->uio_resid;
T> -else
T> -nbytes = 0;
T> -}
T> -mh = m_uiotombuf(hdr_uio, M_WAITOK, 0, 0, 0);
T> -hdrlen = m_length(mh, &mhtail);
T> -} else
T> -hdrlen = 0;
T> -
T>  rem = nbytes ? omin(nbytes, obj_size - offset) : obj_size - offset;
T>  
T>  /*
T> @@ -668,11 +652,23 @@ retry_space:
T>  SOCKBUF_UNLOCK(&so->so_snd);
T>  
T>  /*
T> - * Reduce space in the socket buffer by the size of
T> - * the header mbuf chain.
T> - * hdrlen is set to 0 after the first loop.
T> + * At the beginning of the first loop check if any headers
T> +   

Second call for 2016Q1 quarterly status report submissions

[Benjamin Kaduk]

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is April 7,
2016, for work done in January through March -- less than two weeks away!

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

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

We are looking forward to all of your 2016Q1 reports!

Thanks,

Ben (on behalf of monthly@)

[1] http://www.freebsd.org/cgi/monthly.cgi
[2] http://www.freebsd.org/news/status/report-sample.xml
[3] http://www.freebsd.org/news/status/howto.html
[4] http://www.freebsd.org/news/status/report-2015-07-2015-09.html
[5] http://www.freebsd.org/news/status/report-2015-10-2015-12.html
___
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: CURRENT slow and shaky network stability

[O. Hartmann]

On Mon, 28 Mar 2016 14:52:09 -0700 (PDT)
Don Lewis  wrote:

> On 28 Mar, O. Hartmann wrote:
> > Am Sat, 26 Mar 2016 14:26:45 -0700 (PDT)
> > Don Lewis  schrieb:
> >   
> >> On 26 Mar, Michael Butler wrote:  
> >> > -current is not great for interactive use at all. The strategy of
> >> > pre-emptively dropping idle processes to swap is hurting .. big time.
> >> > 
> >> > Compare inactive memory to swap in this example ..
> >> > 
> >> > 110 processes: 1 running, 108 sleeping, 1 zombie
> >> > CPU:  1.2% user,  0.0% nice,  4.3% system,  0.0% interrupt, 94.5% idle
> >> > Mem: 474M Active, 1609M Inact, 764M Wired, 281M Buf, 119M Free
> >> > Swap: 4096M Total, 917M Used, 3178M Free, 22% Inuse
> >> > 
> >> >   PID USERNAME   THR PRI NICE   SIZERES STATE   C   TIMEWCPU
> >> > COMMAND
> >> >  1819 imb  1  280   213M 11284K select  1 147:44   5.97%
> >> > gkrellm
> >> > 59238 imb 43  200   980M   424M select  0  10:07   1.92%
> >> > firefox
> >> > 
> >> >  .. it shouldn't start randomly swapping out processes because they're
> >> > used infrequently when there's more than enough RAM to spare ..
> >> 
> >> I don't know what changed, and probably something can use some tweaking,
> >> but paging out idle processes isn't always the wrong thing to do.  For
> >> instance if I'm using poudriere to build a bunch of packages and its
> >> heavy use of tmpfs is pushing the machine into many GB of swap usage, I
> >> don't want interactive use like:
> >>vi foo.c
> >>cc foo.c
> >>vi foo.c
> >> to suffer because vi and cc have to be read in from a busy hard drive
> >> each time while unused console getty and idle sshd processes in a bunch
> >> of jails are still hanging on to memory even though they haven't
> >> executed any instructions since shortly after the machine was booted
> >> weeks ago.
> >>   
> >> > It also shows up when trying to reboot .. on all of my gear, 90 seconds
> >> > of "fail-safe" time-out is no longer enough when a good proportion of
> >> > daemons have been dropped onto swap and must be brought back in to flush
> >> > their data segments :-(
> >> 
> >> That's a different and known problem.  See:
> >> 
> >>   
> > 
> > CURRENT has rendered unusable and faulty. Updating ports for poudriere ends
> > up in this error/broken pipe from remote console:
> > 
> >  [~] poudriere ports -u -p head
> > [00:00:00] >> Updating portstree "head"
> > [00:00:00] >> Updating the ports tree... done
> > root@gate [~] Fssh_packet_write_wait: Connection to 192.168.250.111 port
> > 22: Broken pipe
> > 
> > 
> > Although not under load, several processes over time gets idled/paged out -
> > and they never recover, the connection is then sabott, the whole thing
> > unusable :-(  
> 
> I'm definitely not seeing that here.  This is getting close to the end
> of a big poudriere run:
> 
> last pid: 82549;  load averages: 20.05, 20.72, 23.51up 5+12:34:14
> 12:51:55 144 processes: 20 running, 109 sleeping, 15 stopped
> CPU: 85.3% user,  0.0% nice, 14.7% system,  0.0% interrupt,  0.0% idle
> Mem: 1082M Active, 19G Inact, 9718M Wired, 249M Buf, 1095M Free
> ARC: 3841M Total, 2039M MFU, 642M MRU, 3395K Anon, 111M Header, 1044M Other
> Swap: 40G Total, 9691M Used, 31G Free, 23% Inuse, 196K In
> 
> At the moment, openoffice-4, openoffice-devel, libreoffice, and chromium
> are all being built and are using tmpfs for "wrkdir data localbase", so
> there are many GB of data in tmpfs, which is the reason for the high
> inact and swap usage.  I just hit the return key in an idle (for a
> couple of hours) terminal window containing an ssh login session to the
> same machine.  I got a fresh command prompt essentially instantaneously.
> It couldn't have taken more than a couple hundred milliseconds to wake
> up and page in the idle sshd and shell processes on the build server.
> 
> [a couple hours later, after poudriere is done and all tmpfs is gone]
> 
> last pid: 66089;  load averages:  0.13,  1.59,  4.61up 5+14:14:33
> 14:32:14 71 processes:  1 running, 55 sleeping, 15 stopped
> CPU:  3.1% user,  0.0% nice,  0.0% system,  0.0% interrupt, 96.9% idle
> Mem: 58M Active, 85M Inact, 12G Wired, 249M Buf, 19G Free
> ARC: 6249M Total, 2792M MFU, 2246M MRU, 16K Anon, 133M Header, 1078M Other
> Swap: 40G Total, 81M Used, 40G Free
> 
> [after tracking down and exiting all of those stopped processes]
> 
> last pid: 66103;  load averages:  0.20,  0.99,  3.80up 5+14:17:18
> 14:34:59 56 processes:  1 running, 55 sleeping
> CPU:  0.0% user,  0.0% nice,  0.1% system,  0.1% interrupt, 99.9% idle
> Mem: 57M Active, 88M Inact, 12G Wired, 249M Buf, 19G Free
> ARC: 6251M Total, 2793M MFU, 2247M MRU, 16K Anon, 133M Header, 1078M Other
> Swap: 40G Total, 63M Used, 40G Free
> 
> The biggest chunk of the 63 MB of swap appears to be nginx.  It's
> process size is 29 MB, but it has zero resident.  It hasn'