DHCP no longer working for em(4): networkmgr issue 56 (and /var/log/messages weirdness)

[Graham Perrin]

On 27/04/2021 12:33, David Wolfskill wrote:


I am not seeing the issue.



Thanks for checking.

I realised a cause of the problem after reading 
, which led me 
to report .


 updated to 5.0 
on 23rd April.


I wonder why I see no log of the update:

root@mowa219-gjp4-8570p:/var/log # ls -ahlrt messages*
-rw-r--r--  1 root  wheel    61K Mar  5 09:00 messages.4.bz2
-rw-r--r--  1 root  wheel    71K Mar 16 18:00 messages.3.bz2
-rw-r--r--  1 root  wheel    63K Mar 31 15:00 messages.2.bz2
-rw-r--r--  1 root  wheel    53K Apr 15 11:00 messages.1.bz2
-rw-r--r--  1 root  wheel    62K Apr 26 06:00 messages.0.bz2
-rw-r--r--  1 root  wheel   809K May  3 00:48 messages
root@mowa219-gjp4-8570p:/var/log # bzcat messages.1.bz2 | grep networkmgr
root@mowa219-gjp4-8570p:/var/log # bzcat messages.0.bz2 | grep networkmgr
root@mowa219-gjp4-8570p:/var/log # cat messages | grep networkmgr
May  3 00:40:20 mowa219-gjp4-8570p pkg[41146]: networkmgr-5.0 deinstalled
root@mowa219-gjp4-8570p:/var/log #

Related:

bectl, chroot, pkg upgrade, no record of the upgrade in /var/log/messages


___
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: bectl, chroot, pkg upgrade, no record of the upgrade in /var/log/messages

[Graham Perrin]

Thank you,

On 02/05/2021 14:21, Toomas Soome wrote:

… if anything else is logged (syslog or direct file write), it will be in old 
BE.


I wondered about that. In the text attachment to my previous e-mail,

ls -hl /tmp/huh/var/log

– listed a few items, but not messages.


Unless /var/log is created as shared dataset.

It's a simple ZFS file system.
___
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: bectl, chroot, pkg upgrade, no record of the upgrade in /var/log/messages

[Toomas Soome via freebsd-current]

BE as snapshot + clone? zpool history has that fact, but if anything else is 
logged (syslog or direct file write), it will be in old BE. Unless /var/log is 
created as shared dataset.

Sent from my iPhone

> On 2. May 2021, at 14:42, Graham Perrin  wrote:
> 
> This morning I created a boot environment, mounted it at
> 
> /tmp/up
> 
> – then chroot to /tmp/up and at 09:52,
> 
> pkg upgrade -y -r FreeBSD
> 
> Upgrade succeeded. I activated then unmounted the environment, restarted.
> 
> No record of the upgrade in /var/log/messages – is this normal?
> 
> <2021-05-02 10:48 messages without a record of recent pkg upgrade.txt>
> ___
> 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"

bectl, chroot, pkg upgrade, no record of the upgrade in /var/log/messages

[Graham Perrin]

This morning I created a boot environment, mounted it at

/tmp/up

– then chroot to /tmp/up and at 09:52,

pkg upgrade -y -r FreeBSD

Upgrade succeeded. I activated then unmounted the environment, restarted.

No record of the upgrade in /var/log/messages – is this normal?

% date ; uptime ; uname -v
Sun  2 May 2021 10:48:41 BST
10:48a.m.  up 11 mins, 5 users, load averages: 0.42, 1.45, 1.07
FreeBSD 14.0-CURRENT #93 main-n246330-5eb9c93a20d: Tue Apr 27 05:14:26 BST 2021 
root@mowa219-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG 
% grep pkg /var/log/messages | grep -v deinstalled
Apr 26 20:03:02 mowa219-gjp4-8570p pkg[80275]: treeline-3.1.4_2 installed
Apr 26 20:07:37 mowa219-gjp4-8570p pkg[80688]: hnb-1.9.18 installed
Apr 26 20:22:53 mowa219-gjp4-8570p pkg[89092]: wx30-gtk3-3.0.5.1 installed
Apr 26 20:22:55 mowa219-gjp4-8570p pkg[89092]: py37-wxPython40-4.0.7_1 installed
Apr 26 20:51:56 mowa219-gjp4-8570p pkg[93048]: qutebrowser-2.2.0 installed
Apr 27 06:25:59 mowa219-gjp4-8570p pkg-static[5639]: 
drm-devel-kmod-5.4.92.g20210419 installed
Apr 27 06:26:18 mowa219-gjp4-8570p pkg-static[7041]: 
gpu-firmware-kmod-g20210330 installed
Apr 27 15:23:50 mowa219-gjp4-8570p pkg[44522]: python38-3.8.9 installed
Apr 27 15:23:50 mowa219-gjp4-8570p pkg[44522]: py38-setuptools-44.0.0 installed
May  1 21:13:28 mowa219-gjp4-8570p pkg[6313]: python39-3.9.4 installed
May  1 21:14:38 mowa219-gjp4-8570p pkg[6390]: py39-setuptools-44.0.0 installed
May  1 21:14:38 mowa219-gjp4-8570p pkg[6390]: py39-sqlite3-3.9.4_7 installed
May  1 21:14:38 mowa219-gjp4-8570p pkg[6390]: mpg123 reinstalled: 1.26.5 -> 
1.26.5 
May  1 21:17:43 mowa219-gjp4-8570p pkg[6554]: py38-tkinter upgraded: 3.7.10_6 
-> 3.8.9_6 
May  1 21:17:46 mowa219-gjp4-8570p pkg[6554]: py38-numpy reinstalled: 1.16.6,1 
-> 1.16.6,1 
May  1 21:22:38 mowa219-gjp4-8570p pkg[6806]: python-3.7_3,2 installed
May  1 21:44:23 mowa219-gjp4-8570p kernel: pid 29584 (pkg), jid 0, uid 0: 
exited on signal 6 (core dumped)
May  1 21:47:51 mowa219-gjp4-8570p kernel: pid 29621 (pkg), jid 0, uid 0: 
exited on signal 6 (core dumped)
May  1 21:50:36 mowa219-gjp4-8570p pkg[29809]: py37-wxPython40-4.0.7_1 installed
May  1 21:50:37 mowa219-gjp4-8570p pkg[29809]: jansson reinstalled: 2.13.1 -> 
2.13.1 
May  1 21:50:37 mowa219-gjp4-8570p kernel: pid 29809 (pkg), jid 0, uid 0: 
exited on signal 6 (core dumped)
May  1 22:32:40 mowa219-gjp4-8570p kernel: pid 30078 (pkg), jid 0, uid 0: 
exited on signal 6 (core dumped)
May  1 22:32:54 mowa219-gjp4-8570p pkg-static[31747]: pkg-1.16.3 installed
May  2 01:23:57 mowa219-gjp4-8570p kernel: pid 39149 (pkg), jid 0, uid 0: 
exited on signal 6 (core dumped)
May  2 01:25:04 mowa219-gjp4-8570p kernel: pid 39214 (pkg), jid 0, uid 0: 
exited on signal 6 (core dumped)
May  2 01:25:40 mowa219-gjp4-8570p kernel: pid 39246 (pkg), jid 0, uid 0: 
exited on signal 6 (core dumped)
May  2 01:26:39 mowa219-gjp4-8570p pkg[39299]: py37-pip-20.3.4 installed
May  2 01:26:41 mowa219-gjp4-8570p pkg[39299]: pkg reinstalled: 1.16.3 -> 
1.16.3 
May  2 01:26:41 mowa219-gjp4-8570p pkg[39299]: py37-pbr-5.5.0 installed
May  2 01:26:42 mowa219-gjp4-8570p pkg[39299]: flac reinstalled: 1.3.3 -> 1.3.3 
May  2 01:31:10 mowa219-gjp4-8570p pkg[39546]: py37-pip reinstalled: 20.3.4 -> 
20.3.4 
May  2 01:32:56 mowa219-gjp4-8570p pkg[39613]: python37 reinstalled: 3.7.10 -> 
3.7.10 
May  2 01:35:15 mowa219-gjp4-8570p pkg[39765]: py37-pbr-5.5.0 installed
May  2 09:51:30 mowa219-gjp4-8570p pkg[62734]: plank-0.11.89 installed
% bectl list -c creation
BEActive Mountpoint Space Created
r357746-Waterfox  -  -  59.2G 2020-03-10 18:24
n245827-361e9501800-a -  -  10.9G 2021-04-05 18:48
n246123-21afed4b1d1-f -  -  894M  2021-04-26 03:18
n246330-5eb9c93a20d-a -  -  112M  2021-04-27 06:14
n246330-5eb9c93a20d-b -  -  123M  2021-05-01 17:44
n246330-5eb9c93a20d-c NR /  117G  2021-05-02 09:52
% sudo bectl mount n246330-5eb9c93a20d-b /tmp/huh
Successfully mounted n246330-5eb9c93a20d-b at /tmp/huh
% grep pkg /tmp/huh/var/log/messages | grep -v deinstalled
grep: /tmp/huh/var/log/messages: No such file or directory
% ls -hl /tmp/huh/var/log
total 1
-rw-r--r--  1 rootwheel518B 31 Jan 04:52 bsdstats
drwxr-xr-x  2 clamav  clamav 2B 26 Jan 11:55 clamav
drwxr-xr-x  2 rootwheel  3B 30 Mar  2020 ConsoleKit
drwxr-xr-x  2 rootwheel  2B 31 Jan 03:58 cups
drwxrwx--T  2 gdm gdm2B 21 Feb 04:38 gdm
-rw-r--r--  1 rootwheel372K 21 Jun  2020 init.log
drwxrwxr-x  2 rootwheel  2B 21 Jan 03:30 onedrive
drwxr-xr-x  2 rootwheel  2B 31 Jan 04:09 samba4
-rw-r--r--  1 rootwheel2.7K 13 Sep  2020 sddm.log
drwx--  2 rootwheel  2B 18 Apr 16:21 sssd
drwxr-x---  2 _tor_tor   2B 26 Jan 23:52 tor
-rw---  1 rootwheel216B 23 Feb 08:44 userlog
-rw-r--r--  1 rootwheel 21K 13 Sep  2020 Xorg.0.log
-rw-r--r--  1 rootwheel 12K 

Re: Problems with realtek NIC

[Stefan Esser]

Am 02.05.21 um 01:37 schrieb Greg Rivers:
> On Saturday, 1 May 2021 16:45:03 CDT Stefan Esser wrote:
>> Am 01.05.21 um 21:48 schrieb Greg Rivers via freebsd-current:
>>> On Saturday, 1 May 2021 14:09:46 CDT Nilton Jose Rizzo wrote:
 I using a FreeBSD 14-Current and get random error with my NIC. The 
 watchdog timer send a timeout message and I loose connection temporaly. In 
logs show only this message:

>>> Switch to the official Realtek driver in ports: net/realtek-re-kmod
>>
>> The "official" RealTek driver is based on a very old version of "our"
>> driver that was written by Bill Paul.
>>
>> It lacks many features that have been introduced in FreeBSD in the
>> last decade (or even earlier) like NETMAP-Support.
>>
>> The RealTek-driver has special cases for some 50 variants of RealTek
>> Ethernet chips and contains individual firmware patches for nearly all
>> of them.
>>
>> I had started to merge chip specific changes from the official driver
>> to the FreeBSD driver in the hope to get it to support the RTL8125A/B
>> chips. But I have stopped that project for lack of RTL8125 documentation,
>> especially regarding the PHY, which has its own driver module in our
>> version but not the RealTek code. (And somebody claimed to know that
>> another FreeBSD developer was working on RTL8125 support but did not
>> tell who that might be and whether he had documentation.)
>>
>> Anyway, there are changes regarding the initialization and error recovery
>> of different RealTek chips in the official driver that could be merged
>> into our version. But I do not know whether these changes require the
>> firmware changes provided by the RealTek driver to correctly work.
>>
> Thanks for the information Stefan, and for your work on FreeBSD. My use
> of the term "official" was apparently inaccurate. I was not aware of the
> deficiencies in the RealTek driver. I would prefer to use the FreeBSD
> driver, but I don't for purely pragmatic reasons: the FreeBSD driver
> continually locks up and resets under load (as described by the OP),
> while the RealTek driver does not.

Hi Greg,

the RealTek driver is "official" in the sense that it is provided by the
vendor and written with knowledge about all the (many!) deficiencies of
the RealTek Ethernet chips. And yes, the FreeBSD drived definitely needs
work to fully support all variants of the RealTek chip. I guess that due
to uncovered chip specifics or hardware issues, the FreeBSD driver will
often lack the special code (or firmware patches) and will have to recover
chip operations be going through a hard reset.

If you look at the "official" driver sources, you'll find #ifdefs for
FreeBSD versions  before 4.9, but that is not the reason the main driver
source file is more than 3 lines long.

The driver distinguishes between more than 70 different chip versions
(identified by MACFG_3 to MACFG_84 with some IDs missing). And each one
has specific requirements regarding firmware patches, initialization and
reset behavior, error handling, ...

I have analyzed these differences (see the attached file) but for lack
of RTL8125 documentation not preceded with this project at this time.
(The column lx_fw identifies firmware patches used by the Linux driver,
while rt_fw identifies those embedded into the RealTek driver for
FreeBSD - and those differ somewhat, and I have no idea why ...).

I have local modifications of the re driver in my sources, but have
one other project that I really want to get ready in the next few
months (after working on it for nearly 2 years) and I do not want to
become responsible for issues of the RealTek driver in base (after
committing fixes that also might cause regressions, if they need to
be accompanied by firmware patches ...)

> FWIW, here are the particulars on the RealTek chip-set that I've got:
> 
> re0:  port 
> 0xe000-0xe0ff mem 0xb0804000-0xb0804fff,0xb080-0xb0803fff irq 16 at 
> device 0.0 on pci1
> re0: Using 1 MSI-X message
> re0: Chip rev. 0x2c80
> re0: MAC rev. 0x0010

The Chip rev. indicates that you have got a RTL8168E_VL, which does not
need a firmware patch according to RealTek driver, but gets one in Linux.

It is identified by MACFG_38 in the RealTek driver, BTW, and there are
only a few chip specific code fragments relevant to that chip. It seems,
it needs special handling when the MAC address is programmed, but I did
not spot any other special code for that particular chip in the "official"
driver.

> re0@pci0:1:0:0: class=0x02 rev=0x06 hdr=0x00 vendor=0x10ec device=0x8168 
> subvendor=0x1458 subdevice=0xe000
> vendor = 'Realtek Semiconductor Co., Ltd.'
> device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
> class  = network
> subclass   = ethernet
> 
> Would the FreeBSD Foundation be able to help with getting documentation 
from RealTek?

I have no idea - there is a RTL8125 driver in OpenBSD (which is separate
from the RTL8111/8168 drivers, there) and that