Re: Spectre/Meltdown mitigation in 11.1-p10 bogging down zfs send/receive?

[Julian Elischer]

On 14/5/18 11:48 pm, Patrick M. Hausen wrote:

Hi!


Am 14.05.2018 um 17:35 schrieb Patrick M. Hausen :
Possibly we are on the wrong track altogether.

We were - please just forget it ...


Isn't it a fact that you will always discover your own problem 
immediately after posting for help from the entire world?

I'm sure it is a corollary to Murphy's law.


ZFS scrub running during our activity ... everybody who already put
more than five minutes of thought into this deserves a beer at the next
EuroBSDCon ;-)

Patrick



___
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: USB GSM still in trouble after upgrade to 11.1-RELEASE-p10

[Per olof Ljungmark]

On 05/14/18 16:35, Willem Jan Withagen wrote:
> Hi,
> 
> Yesterday evening I upgraded a system to 11.1-RELEASE-p10.
> But that sort of upset my GSM-dongle I use for alarming.
> 
> And it did not do that before the upgrade, where I was running -p9.
> 
> 
> This is what I find repeated at rather high frequency in the logs:
> +ugen1.3:  at usbus1
> +u3g0 on uhub3
> +u3g0:  on usbus1
> +u3g0: Found 2 ports.
> +umass0 on uhub3
> +umass0:  addr 3> on usbus1
> +umass0:  SCSI over Bulk-Only; quirks = 0x
> +umass0:3:0: Attached to scbus3
> +(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
> +(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
> +(probe0:umass-sim0:0:0:0): Retrying command
> +(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
> +(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
> +(probe0:umass-sim0:0:0:0): Retrying command
> +(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
> +(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
> +(probe0:umass-sim0:0:0:0): Retrying command
> +(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
> +(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
> +(probe0:umass-sim0:0:0:0): Retrying command
> +(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
> +(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
> +(probe0:umass-sim0:0:0:0): Error 5, Retries exhausted
> +ugen1.3:  at usbus1 (disconnected)
> +u3g0: at uhub3, port 2, addr 3 (disconnected)
> +u3g0: detached
> +umass0: at uhub3, port 2, addr 3 (disconnected)
> +umass0: detached
> 
> So when I get home, I'm going to pull the stick.
> But what could be going on here?

I have identical behavior on a
FreeBSD 11.1-STABLE #0 r330526
system after it was restarted today.

It used to work with a Huawei E398 but after the reboot it does not,
just like your above.

Interestingly, I replaced it with a much older Huawei E1750 and that one
worked, but only after I rebooted again.

With the E398 after a reboot I only see /dev/cuau1, no cuaUX.X
If I pull it and replace with E1750 nothing happens
If I reboot with the E1750 in place, I get /dev/cuaUX.X

Fishy...


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

[Bug 215471] Using bsnmpd with the snmp_hostres module on a vmware ESXi guest with a disconnected CD drive uses 100% CPU

[bugzilla-noreply]

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

Conrad Meyer  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 CC||c...@freebsd.org
 Status|In Progress |Closed

--- Comment #8 from Conrad Meyer  ---


*** This bug has been marked as a duplicate of bug 209368 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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: Spectre/Meltdown mitigation in 11.1-p10 bogging down zfs send/receive?

[Patrick M. Hausen]

Hi!

> Am 14.05.2018 um 17:35 schrieb Patrick M. Hausen :
> Possibly we are on the wrong track altogether.

We were - please just forget it ...

ZFS scrub running during our activity ... everybody who already put
more than five minutes of thought into this deserves a beer at the next
EuroBSDCon ;-)

Patrick
-- 
punkt.de GmbH   Internet - Dienstleistungen - Beratung
Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100
76133 Karlsruhe i...@punkt.de   http://punkt.de
AG Mannheim 108285  Gf: Juergen Egeling

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

Spectre/Meltdown mitigation in 11.1-p10 bogging down zfs send/receive?

[Patrick M. Hausen]

Hey guys,

as some might know we run our hosting products in ZFS and iocage based
jails. The backup concept relies on recurring local snapshots and a copy of
these on one (more planned) central storage server. The storage server
does essentially nothing but run zfs receive for each dataset on each
hosting node. 12x spinning rust and 128G of RAM. Lots of space ;-)

In preparation of rolling out (among other patches) the Meltdown and Spectre
mitigation fixes and microcode updates we already ran benchmarks that
measured our primary applications - the TYPO3 and Neos CMS. We did not
see much of an impact.

We updated that central storage system last Friday.

Today we provisioned a new server meaning a new hosting hardware and
a couple of jails on that one. The new system already has got all the latest
patches.
Part of the provisioning process is creating an initial snapshot of every 
dataset
and sending an initial copy to the storage server, so we can send nightly
incrementals.

That step took surprisingly long for the first of the new jails.

At least an order of magnitude, I cannot provide exact measurements yet,
because this is all part of rather complex Ansible task and it really caught us 
by
surprise.

We already received a couple of warnings from the Icinga service monitoring
the nightly replication runs - we still need to investigate this. We suspect 
they
ran slower than usual, too.

To narrow down the cause of the problem we tried this in chronological order:

1. storage server (receiving end):

Disable microcode update and hw.ibrs_active still slow
Disable vm.pmap.pti still 
slow

2. new jail host (sending end):

Disable both
fast
Re-enable microcode update and hw.ibrs_active   still fast
Re-enable vm.pmap.pti   still 
fast

Reboot as necessary, of course. And we double checked the current value
of the respective sysctls before running the tests.

That last step is *quite* unexpected, because it just does not make sense to me.


Does anybody know what impact the fixes, both PTI and IBRS are *expected*
to have on bulk zfs send/receive operations from/to two different hosts?

Possibly we are on the wrong track altogether. We suspected the CPU fixes
because of the general "what did you change last" approach ...


Thank you very much
Patrick
-- 
punkt.de GmbH   Internet - Dienstleistungen - Beratung
Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100
76133 Karlsruhe i...@punkt.de   http://punkt.de
AG Mannheim 108285  Gf: Juergen Egeling

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

USB GSM still in trouble after upgrade to 11.1-RELEASE-p10

[Willem Jan Withagen]

Hi,

Yesterday evening I upgraded a system to 11.1-RELEASE-p10.
But that sort of upset my GSM-dongle I use for alarming.

And it did not do that before the upgrade, where I was running -p9.


This is what I find repeated at rather high frequency in the logs:
+ugen1.3:  at usbus1
+u3g0 on uhub3
+u3g0:  on usbus1
+u3g0: Found 2 ports.
+umass0 on uhub3
+umass0:  on usbus1
+umass0:  SCSI over Bulk-Only; quirks = 0x
+umass0:3:0: Attached to scbus3
+(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
+(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
+(probe0:umass-sim0:0:0:0): Retrying command
+(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
+(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
+(probe0:umass-sim0:0:0:0): Retrying command
+(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
+(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
+(probe0:umass-sim0:0:0:0): Retrying command
+(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
+(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
+(probe0:umass-sim0:0:0:0): Retrying command
+(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
+(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
+(probe0:umass-sim0:0:0:0): Error 5, Retries exhausted
+ugen1.3:  at usbus1 (disconnected)
+u3g0: at uhub3, port 2, addr 3 (disconnected)
+u3g0: detached
+umass0: at uhub3, port 2, addr 3 (disconnected)
+umass0: detached

So when I get home, I'm going to pull the stick.
But what could be going on here?

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

Pós-graduação em Engenharia de Automação e Controle Industrial

[FIERGS | FATEC - Faculdade SENAI de Tecnologia]

___
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: extract the process arguments from the crashdump

[Eugene M. Zheganin]

Hello,

On 14.05.2018 18:12, Konstantin Belousov wrote:

On Mon, May 14, 2018 at 05:32:21PM +0500, Eugene M. Zheganin wrote:


Well, unfortunately this gives me exactly same information as the
core.X.txt file contains - process names without arguments, and I really
want to know what arguments ctladm had when the system has crashed:

Most likely the in-kernel cache for the process arguments was dropped.


Is there anything I can do to prevent this from happening, so if the 
system will crash next time I will get processes arguments extractable 
(in this case I would still like to get the arguments information) ?



Thanks.

Eugene.

___
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: extract the process arguments from the crashdump

[Konstantin Belousov]

On Mon, May 14, 2018 at 05:32:21PM +0500, Eugene M. Zheganin wrote:
> Hello,
> 
> On 14.05.2018 16:15, Konstantin Belousov wrote:
> > On Mon, May 14, 2018 at 01:02:28PM +0500, Eugene M. Zheganin wrote:
> >> Hello,
> >>
> >>
> >> Is there any way to extract the process arguments from the system
> >> crashdump ? If yes, could anyone please explain to me how do I do it.
> > ps -M vmcore.file -N /boot/mykernel/kernel -auxww
> 
> Well, unfortunately this gives me exactly same information as the 
> core.X.txt file contains - process names without arguments, and I really 
> want to know what arguments ctladm had when the system has crashed:

Most likely the in-kernel cache for the process arguments was dropped.
___
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: extract the process arguments from the crashdump

[Eugene M. Zheganin]

Hello,

On 14.05.2018 16:15, Konstantin Belousov wrote:

On Mon, May 14, 2018 at 01:02:28PM +0500, Eugene M. Zheganin wrote:

Hello,


Is there any way to extract the process arguments from the system
crashdump ? If yes, could anyone please explain to me how do I do it.

ps -M vmcore.file -N /boot/mykernel/kernel -auxww


Even if I ask ps explicitely to give me args, for some reason it ignores 
the format and 'args' keyword seems to be an alias for 'comm', but with 
square brackets:



[root@san1:esx/r332096M]# ps -M vmcore.4 -N /boot/kernel/kernel -axo 
'pid,ppid,comm,args'

  PID  PPID COMMANDCOMMAND
0 0 kernel [kernel]
1 0 init   [init]
2 0 crypto [crypto]
3 0 crypto returns [crypto returns]
4 0 cam[cam]
5 0 soaiod1[soaiod1]
6 0 soaiod2[soaiod2]
7 0 soaiod3[soaiod3]
8 0 soaiod4[soaiod4]
9 0 zfskern[zfskern]
   10 0 audit  [audit]
   11 0 idle   [idle]
   12 0 intr   [intr]
   13 0 geom   [geom]
   14 0 usb[usb]
   15 0 sctp_iterator  [sctp_iterator]
   16 0 pf purge   [pf purge]
   17 0 rand_harvestq  [rand_harvestq]
   18 0 enc_daemon0[enc_daemon0]
   19 0 enc_daemon1[enc_daemon1]
   20 0 enc_daemon2[enc_daemon2]
   21 0 g_mirror swap  [g_mirror swap]
   22 0 pagedaemon [pagedaemon]
   23 0 vmdaemon   [vmdaemon]
   24 0 pagezero   [pagezero]
   25 0 bufdaemon  [bufdaemon]
   26 0 bufspacedaemon [bufspacedaemon]
   27 0 syncer [syncer]
   28 0 vnlru  [vnlru]
  114 1 adjkerntz  [adjkerntz]
  593 1 moused [moused]
  606 1 devd   [devd]
  701 1 syslogd[syslogd]
  784 1 watchdogd  [watchdogd]
  866 0 ctl[ctl]
  868 1 ctld   [ctld]
  894 1 zabbix_agentd  [zabbix_agentd]
  898   894 zabbix_agentd  [zabbix_agentd]
  901   894 zabbix_agentd  [zabbix_agentd]
  905   894 zabbix_agentd  [zabbix_agentd]
  907   894 zabbix_agentd  [zabbix_agentd]
  949 1 ntpd   [ntpd]
  968 1 nginx  [nginx]
  978 0 ng_queue   [ng_queue]
 1069 1 sshd   [sshd]
 1151 1 sendmail   [sendmail]
 1154 1 sendmail   [sendmail]
 1158 1 cron   [cron]
 1197 1 bsnmpd [bsnmpd]
 1200 1 blacklistd [blacklistd]
 1210 1 getty  [getty]
 1211 1 getty  [getty]
 1212 1 getty  [getty]
 1213 1 getty  [getty]
 1214 1 getty  [getty]
 1215 1 getty  [getty]
 1216 1 getty  [getty]
 1217 1 getty  [getty]
 1218 1 getty  [getty]
12970   968 nginx  [nginx]
12971   968 nginx  [nginx]
12972   968 nginx  [nginx]
12973   968 nginx  [nginx]
12974   968 nginx  [nginx]
12975   968 nginx  [nginx]
12976   968 nginx  [nginx]
12977   968 nginx  [nginx]
12978   968 nginx  [nginx]
12979   968 nginx  [nginx]
12980   968 nginx  [nginx]
12981   968 nginx  [nginx]
12982   968 nginx  [nginx]
12983   968 nginx  [nginx]
12984   968 nginx  [nginx]
12985   968 nginx  [nginx]
12986   968 nginx  [nginx]
32835  1069 sshd   [sshd]
32884 32835 sshd   [sshd]
32885 32884 zsh[zsh]
32929 32885 su [su]
32948 32929 csh[csh]
32964 32948 sh [sh]
32965 32964 mc [mc]
32966 32965 csh[csh]
48747 67993 sudo   [sudo]
48750 67988 sudo   [sudo]
48757 48750 zfs[zfs]
48758 48747 zfs[zfs]
48759 67990 sudo   [sudo]
48762 48759 zfs[zfs]
48765 67997 sudo   [sudo]
48766 48765 zfs[zfs]
48769 67984 sudo   [sudo]
48770 48769 zfs[zfs]
48771 67996 sudo   [sudo]
48772 48771 zfs[zfs]
48785 67991 sudo   [sudo]
48786 48785 ctladm [ctladm]
48787 67983 sudo   [sudo]
48788 48787 ctladm [ctladm]
48789 67986 sudo   [sudo]
48790 48789 ctladm [ctladm]
48791 67985 sudo   [sudo]
48792 48791 ctladm [ctladm]
48796 67987 sudo   [sudo]
48797 48796 zfs[zfs]
67980 1 uwsgi  [uwsgi]
67981 67980 uwsgi  [uwsgi]
67982 67980 uwsgi  [uwsgi]
67983 67980 uwsgi  [uwsgi]
67984 67980 uwsgi  [uwsgi]
67985 67980 uwsgi  [uwsgi]
67986 67980 uwsgi  [uwsgi]
67987 67980 uwsgi  [uwsgi]
67988 67980 uwsgi  [uwsgi]
67989 67980 uwsgi  [uwsgi]
67990 67980 uwsgi  [uwsgi]
67991 67980 uwsgi  [uwsgi]
67992 67980 uwsgi  [uwsgi]
67993 67980 uwsgi  [uwsgi]
67994 67980 uwsgi  [uwsgi]
67995 67980 uwsgi  [uwsgi]
67996 

Re: extract the process arguments from the crashdump

[Eugene M. Zheganin]

Hello,

On 14.05.2018 16:15, Konstantin Belousov wrote:

On Mon, May 14, 2018 at 01:02:28PM +0500, Eugene M. Zheganin wrote:

Hello,


Is there any way to extract the process arguments from the system
crashdump ? If yes, could anyone please explain to me how do I do it.

ps -M vmcore.file -N /boot/mykernel/kernel -auxww


Well, unfortunately this gives me exactly same information as the 
core.X.txt file contains - process names without arguments, and I really 
want to know what arguments ctladm had when the system has crashed:



[root@san1:esx/r332096M]# ps -M vmcore.4 -N /boot/kernel/kernel -auxww
USER PID %CPU %MEM VSZ   RSS TT  STAT STARTED 
TIME COMMAND
root   0  0,0  0,0   0 0  -  DLs   1янв.70 2866:37,17 
[kernel]

root   1  0,0  0,0542416  -  DLs   1янв.70 0:03,95 [init]
root   2  0,0  0,0   0 0  -  DL1янв.70 0:00,00 [crypto]
root   3  0,0  0,0   0 0  -  DL1янв.70 0:00,00 
[crypto returns]

root   4  0,0  0,0   0 0  -  RL1янв.70 175:44,92 [cam]
root   5  0,0  0,0   0 0  -  DL1янв.70 0:00,07 [soaiod1]
root   6  0,0  0,0   0 0  -  DL1янв.70 0:00,07 [soaiod2]
root   7  0,0  0,0   0 0  -  DL1янв.70 0:00,07 [soaiod3]
root   8  0,0  0,0   0 0  -  DL1янв.70 0:00,07 [soaiod4]
root   9  0,0  0,0   0 0  -  DL1янв.70 181:27,20 
[zfskern]

root  10  0,0  0,0   0 0  -  DL1янв.70 0:00,00 [audit]
root  11  0,0  0,0   0 0  -  RL1янв.70 183810:56,57 
[idle]

root  12  0,0  0,0   0 0  -  WL1янв.70 131:37,76 [intr]
root  13  0,0  0,0   0 0  -  DL1янв.70 1:33,61 [geom]
root  14  0,0  0,0   0 0  -  DL1янв.70 0:36,74 [usb]
root  15  0,0  0,0   0 0  -  DL1янв.70 0:00,00 
[sctp_iterator]
root  16  0,0  0,0   0 0  -  DL1янв.70 1:38,61 [pf 
purge]
root  17  0,0  0,0   0 0  -  DL1янв.70 1:11,87 
[rand_harvestq]
root  18  0,0  0,0   0 0  -  DL1янв.70 0:00,37 
[enc_daemon0]
root  19  0,0  0,0   0 0  -  DL1янв.70 0:00,38 
[enc_daemon1]
root  20  0,0  0,0   0 0  -  DL1янв.70 0:05,20 
[enc_daemon2]
root  21  0,0  0,0   0 0  -  DL1янв.70 1:03,00 
[g_mirror swap]
root  22  0,0  0,0   0 0  -  DL1янв.70 10:19,64 
[pagedaemon]
root  23  0,0  0,0   0 0  -  DL1янв.70 0:18,40 
[vmdaemon]
root  24  0,0  0,0   0 0  -  DL1янв.70 0:00,01 
[pagezero]
root  25  0,0  0,0   0 0  -  DL1янв.70 0:01,71 
[bufdaemon]
root  26  0,0  0,0   0 0  -  DL1янв.70 0:01,95 
[bufspacedaemon]

root  27  0,0  0,0   0 0  -  DL1янв.70 2:20,07 [syncer]
root  28  0,0  0,0   0 0  -  DL1янв.70 0:03,19 [vnlru]
root 114  0,0  0,06288 0  -  DWs  - 0:00,00 [adjkerntz]
root 593  0,0  0,06600  1860  -  Ds1янв.70 0:00,00 [moused]
root 606  0,0  0,09180   620  -  Ds1янв.70 0:07,76 [devd]
root 701  0,0  0,06420  1928  -  Ds1янв.70 0:26,92 [syslogd]
root 784  0,0  0,03564  3612  -  Ds1янв.70 0:01,46 
[watchdogd]

root 866  0,0  0,0   0 0  -  DL1янв.70 42:20,99 [ctl]
root 868  0,0  0,0  224200  2248  -  Ds1янв.70 20:03,85 [ctld]
zabbix   894  0,0  0,0   12424 0  -  DW   - 0:00,00 [zabbix_agentd]
zabbix   898  0,0  0,0   12424  4504  -  D 1янв.70 1:02,34 
[zabbix_agentd]

zabbix   901  0,0  0,0   12424 0  -  DW   - 0:00,00 [zabbix_agentd]
zabbix   905  0,0  0,0   12424  1580  -  D 1янв.70 3:03,14 
[zabbix_agentd]
zabbix   907  0,0  0,0   12424  1376  -  D 1янв.70 3:05,45 
[zabbix_agentd]

root 949  0,0  0,0   12452 12532  -  Ds1янв.70 0:19,90 [ntpd]
root 968  0,0  0,0 1063848 0  -  DWs  - 0:00,00 [nginx]
root 978  0,0  0,0   0 0  -  DL1янв.70 0:00,00 
[ng_queue]

root1069  0,0  0,0   12848  3780  -  Ds1янв.70 0:06,33 [sshd]
root1151  0,0  0,0   10452  4304  -  Ds1янв.70 0:09,25 
[sendmail]

smmsp   1154  0,0  0,0   10452 0  -  DWs  - 0:00,00 [sendmail]
root1158  0,0  0,06464 0  -  DWs  - 0:00,00 [cron]
root1197  0,0  0,0   10060  5268  -  Ds1янв.70 4:51,59 [bsnmpd]
root1200  0,0  0,06600  2112  -  Ds1янв.70 0:04,13 
[blacklistd]

root1210  0,0  0,06408  1844  -  Ds+   1янв.70 0:00,00 [getty]
root1211  0,0  0,06408  1844  -  Ds+   1янв.70 0:00,00 [getty]
root1212  0,0  0,06408  1844  -  Ds+   1янв.70 0:00,00 [getty]
root1213  0,0  0,06408  1844  -  Ds+   1янв.70 0:00,00 [getty]
root1214  0,0  0,06408  1844  -  Ds+   1янв.70 0:00,00 [getty]
root1215  0,0  0,0

[Bug 221376] 11.1-RELEASE amd64: GENERIC kernel compiled without any CPUTYPE?= in /etc/make.conf fail to boot, but with CPUTYPE?=nocona it work fine

[bugzilla-noreply]

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

Eugene Grosbein  changed:

   What|Removed |Added

 CC||eu...@freebsd.org
   Assignee|b...@freebsd.org|sta...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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: extract the process arguments from the crashdump

[Konstantin Belousov]

On Mon, May 14, 2018 at 01:02:28PM +0500, Eugene M. Zheganin wrote:
> Hello,
> 
> 
> Is there any way to extract the process arguments from the system 
> crashdump ? If yes, could anyone please explain to me how do I do it.

ps -M vmcore.file -N /boot/mykernel/kernel -auxww
___
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: 11.1-RELEASE-p10 cannot compile freebsd stable/11 kernel?

[Konstantin Belousov]

On Sun, May 13, 2018 at 08:06:47PM -0500, Mike Karels wrote:
> [details omittied]
> > > I know that clang has been updated a lot; has the kernel source gotten
> > > ahead of clang on stable/11?
> > On stable/11 they are in sync.  The official method of upgrade is
> > make buildworld buildkernel
> > from older version takes care of the compiler version transparently.
> > If you use config/make, ensure that the installed world is at the
> > compatible level for the kernel sources.
> 
> So the freebsd-update version is not in sync with the -stable branch?
> That was not at all obvious to me.  I upgrade from source on my -current
> test system, but normally use freebsd-update on my production systems
> (until it failed to update the kernel).

freebsd-update never follows stable.  re@ only provides updates for releases,
and for beta/RCs.  11.2-BETA1 was released three days ago, from which moment
you can update to it using freebsd-update.
___
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"

[Bug 215471] Using bsnmpd with the snmp_hostres module on a vmware ESXi guest with a disconnected CD drive uses 100% CPU

[bugzilla-noreply]

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

Eugene Grosbein  changed:

   What|Removed |Added

 CC||ad...@support.od.ua

--- Comment #7 from Eugene Grosbein  ---
*** Bug 217983 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 215471] Using bsnmpd with the snmp_hostres module on a vmware ESXi guest with a disconnected CD drive uses 100% CPU

[bugzilla-noreply]

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

Eugene Grosbein  changed:

   What|Removed |Added

 CC||eu...@freebsd.org
   Assignee|virtualizat...@freebsd.org  |sta...@freebsd.org
   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2093
   ||68
 Status|New |In Progress

--- Comment #6 from Eugene Grosbein  ---
Should be fixed in all supported branches by
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209368

Please check and respond.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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: lagg0 with ue0 and iwm0 is not operate on 11.2-BETA1

[Masachika ISHIZUKA]

>>   My machines have connected WiFi. i.e. They found available WiFi
>> networks and assosiate.
>>   My trouble is not to communicate via ethernet with lagg0.
> 
> it is just what described there
> bellow is my configuration
>
  [snip]
>

  I confirmed that ath0's mac address can be changed by describing
'hint.ath.0.macaddr="00:11:22:33:44:55"' in /boot/loader.conf.
  But the behavior is the same.
  I can communicate via re0 on lagg0, and I can communicate via failovered
ath0 on lagg0, but I can NOT communicate via switched back re0 on lagg0.
  'ifconfig re0 down && ifconfig re0 up' can resume re0.

% cat /etc/rc.conf
ifconfig_re0="up"
wlans_ath0="wlan0"
create_args_wlan0="country JP"
ifconfig_wlan0="wpa up"
cloned_interfaces="lagg0"
ifconfig_lagg0="up laggproto failover laggport re0 laggport wlan0 192.168.x.x 
netmask x.x.x.x"
-- 
Masachika ISHIZUKA
___
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: 11.1-RELEASE-p10 cannot compile freebsd stable/11 kernel?

[Eugene Grosbein]

14.05.2018 8:06, Mike Karels wrote:

> So the freebsd-update version is not in sync with the -stable branch?
> That was not at all obvious to me.  I upgrade from source on my -current
> test system, but normally use freebsd-update on my production systems
> (until it failed to update the kernel).

freebsd-update delivers compiled code for releng/11.1 branch (for example)
and not for stable/11 branch.

releng/* branches have code of corresponding RELEASE plus small number of fixes 
only,
basically security ones.
___
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"

extract the process arguments from the crashdump

[Eugene M. Zheganin]

Hello,


Is there any way to extract the process arguments from the system 
crashdump ? If yes, could anyone please explain to me how do I do it.



Thanks.

Eugene.

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