Seems like I did not cc my reply to the mailing list.
Doing it now because I found a hint which may
lead to the cause of the reboot loop.
Removing:
linux_load="YES"
linprocfs_load="YES"
linsysfs_load="YES"
prevent the reboot loop in multi-user mode but
leave me without Linux emulation...
Regards,
Denis.
Hi Gordon,
this is real hardware. I found the reason (see below).
Setting hw.lazy_fpu_switch=1 in /boot/loader.conf makes no difference.
No panic messages.
I can tell you when it happen. Here is the boot messages:
... skipped ...
Timecounters tick every 1.000 msec
nvme cam probe device init
ugen2.1: <Intel EHCI root HUB> at usbus2
ugen1.1: <Intel UHCI root HUB> at usbus1
ugen0.1: <Intel UHCI root HUB> at usbus0
uhub0: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus2
uhub1: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
uhub2: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
uhub1: 2 ports with 2 removable, self powered
uhub2: 2 ports with 2 removable, self powered
uhub0: 4 ports with 4 removable, self powered
<---- here screen (local monitor) goes black and machine restarted.
ada0 at ata2 bus 0 scbus8 target 0 lun 0
ada0: <WDC WD2000FYYZ-01UL1B1 01.01K02> ATA8-ACS SATA 3.x device
ada0: Serial Number WD-WMC1P0D1KEHJ
ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
ada0: 1907729MB (3907029168 512 byte sectors)
da0 at ciss0 bus 0 scbus0 target 0 lun 0
da0: <HP RAID 5 OK> Fixed Direct Access SCSI device
da0: 135.168MB/s transfers
da0: Command Queueing enabled
da0: 858293MB (1757784604 512 byte sectors)
Trying to mount root from ufs:/dev/da0s1a [rw]...
I noticed that I can boot the *patched* kernel in single user mode.
Removing these 3 lines from the /boot/loader.conf fixed rebooting loop problem:
linux_load="YES"
linprocfs_load="YES"
linsysfs_load="YES"
This machine is used as a test bench to test stuff
before deploying on a production server.
We need Linux emulation support on the production
server to run closed source software...
So... maybe this will help someone.
Blaming evil penguins,
Denis
On 21/06/2018 4:19 PM, Gordon Tetlow wrote:
On Wed, Jun 20, 2018 at 11:14 PM, Denis Polygalov <[email protected]> wrote:
What I did is following:
# uname -a
FreeBSD my_host_name 11.1-RELEASE-p10 FreeBSD 11.1-RELEASE-p10 #0: Tue
May 8 05:21:56 UTC 2018
[email protected]:/usr/obj/usr/src/sys/GENERIC amd64
# freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 11.1-RELEASE from update6.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.
The following files will be updated as part of updating to 11.1-RELEASE-p11:
/boot/kernel/kernel
Installing this update cause endless reboot loop.
# cat /boot/loader.conf
kern.maxfiles="32768"
zfs_load="YES"
linux_load="YES"
linprocfs_load="YES"
linsysfs_load="YES"
# dmesg |grep CPU
CPU: Intel(R) Xeon(TM) CPU 3.40GHz (3400.19-MHz K8-class CPU)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
SMP: AP CPU #1 Launched!
SMP: AP CPU #3 Launched!
SMP: AP CPU #2 Launched!
cpu0: <ACPI CPU> on acpi0
cpu1: <ACPI CPU> on acpi0
cpu2: <ACPI CPU> on acpi0
cpu3: <ACPI CPU> on acpi0
acpi_perf0: <ACPI CPU Frequency Control> on cpu0
est: CPU supports Enhanced Speedstep, but is not recognized.
est: CPU supports Enhanced Speedstep, but is not recognized.
est: CPU supports Enhanced Speedstep, but is not recognized.
The machine is HP ProLiant ML350
Sorry to hear you are having a problem.
Just to confirm, this is running on hardware and not on a Xen
hypervisor, correct?
Assuming it's running directly on the hardware, can you see if setting:
hw.lazy_fpu_switch=1
in /boot/loader.conf makes any difference?
Is there any panic message?
Thanks,
Gordon
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[email protected]"
