[Bug 227422] i386 mini-memstick 11-stable installer not recognized as bootable device on Lenovo x220

[bugzilla-noreply]

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

Bug ID: 227422
   Summary: i386 mini-memstick 11-stable installer not recognized
as bootable device on Lenovo x220
   Product: Base System
   Version: 11.1-STABLE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: misc
  Assignee: b...@freebsd.org
  Reporter: ema...@freebsd.org

I fetched an i386 mini-memstick snapshot image from
https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/11.1/FreeBSD-11.1-STABLE-i386-20180315-r330998-mini-memstick.img.xz
and wrote it to a USB hard drive.

When attempting to boot on a Lenvo x220 laptop the BIOS does not recognize this
as a bootable drive - it appears in the boot selection menu, but choosing it
returns immediately to the selection menu, as occurs with other non-bootable
drives.

For reference, same drive boots and kernel starts on a ASRock J3455B (but the
kernel hangs for other reasons, under investigation elsewhere)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 227422] i386 mini-memstick 11-stable installer not recognized as bootable device on Lenovo x220

[bugzilla-noreply]

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

Allan Jude  changed:

   What|Removed |Added

 CC||allanj...@freebsd.org

--- Comment #2 from Allan Jude  ---
This is likely related to changes Benno has been making.

You might compare what is in that snapshot to what is in the 11.1 release .img


One option is to apply the lenovofix to the images, but it is not clear if that
might cause issues on any other buggy BIOSes.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 222908] Boot hangs on HPET on Intel Apollo Lake

[bugzilla-noreply]

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

--- Comment #4 from Hannes Hauswedell  ---
The workaround does indeed work, other issues are unrelated to this.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 227422] i386 mini-memstick 11-stable installer not recognized as bootable device on Lenovo x220

[bugzilla-noreply]

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

--- Comment #4 from Ed Maste  ---
Or perhaps we should just be using MBR

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 227404] UP FreeBSD VM always hangs on reboot since 20180329-r331740

[bugzilla-noreply]

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

Dexuan Cui  changed:

   What|Removed |Added

 CC||b...@freebsd.org

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 211000] [Hyper-V] Online VHDX Resize doesn't work properly

[bugzilla-noreply]

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

Dexuan Cui  changed:

   What|Removed |Added

 Status|Open|Closed
 Resolution|--- |FIXED

--- Comment #10 from Dexuan Cui  ---
I believe the bug has been fixed, at least in 11.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 194766] [drm:pid12:i915_hangcheck_elapsed] [drm:pid12:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung

[bugzilla-noreply]

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

Michael Danilov  changed:

   What|Removed |Added

 CC||mike.d.ft...@gmail.com

--- Comment #45 from Michael Danilov  ---
Not fixed, ok?

I still get this as of 11.1 -- and been since 10.0 or before, thinking it was
my hardware.

I found a more or less reliable way to cause it: do a lot of 2D graphics --
like drawing something in graphics/inkscape or in WED from games/xptools.
Happens at least once in half an hour and is very annoying.

I don't know if related, but I also often get corruption like missing/blinking
characters in fonts, broken transparency and black areas with dark blue dots
that sometimes move/blink. Sometimes they show up in 3d textures as well.

Should I attach hw.dri.0.info.i915_error_state next time this happens?

Or could anyone at least point me to a setting in the kernel sources defining
how often the hangcheck happens -- so that I have to wait only 10 seconds
instead of sitting there for a whole minute each time it hangs?

Cheers,
Mike

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 227422] i386 mini-memstick 11-stable installer not recognized as bootable device on Lenovo x220

[bugzilla-noreply]

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

--- Comment #1 from Ed Maste  ---
amd64 fails the same way on this hardware when BIOS configured for "legacy
only" boot; UEFI boot is successful.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 194766] [drm:pid12:i915_hangcheck_elapsed] [drm:pid12:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung

[bugzilla-noreply]

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

--- Comment #46 from Michael Danilov  ---
Actually I mean from 10.something, haven't seriously used intel graphics before
that, maybe it was something else.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 227422] i386 mini-memstick 11-stable installer not recognized as bootable device on Lenovo x220

[bugzilla-noreply]

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

--- Comment #3 from Ed Maste  ---
11-1-RELEASE-i386 fails in the same way

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

RE: [Bug 227404] UP FreeBSD VM always hangs on reboot since 20180329-r331740

[Dexuan Cui via freebsd-bugs]

> From: Bruce Evans
> Sent: Tuesday, April 10, 2018 00:45
> 
> On Tue, 10 Apr 2018 a bug that doesn't want repl...@freebsd.org wrote:
> 
> (The bug didn't even Cc freebsd-bugs for this followup.)

Thanks for the reminder! I Cc'd bugs@ just now.

> > --- Comment #4 from Dexuan Cui ---
> ...
> 
> I think I saw this a few months before that.
> 
> My only history of this is that I built a UP kernel on 17 Dec 2017 to see
> if UP kernels had the bug.  So SMP kernels probably had the bug then.
> 
> Bruce

Here the bug is that UP FreeBSD VM hangs on reboot or power-off, and
I'm sure this recent patch (which was commited by Jeff on Mar 26) caused this 
bug:
https://github.com/freebsd/freebsd/commit/63a483ed5f4eaadb8979992c7a5de24c7a471c61
("Fix a bug introduced in r329612 that slowly invalidates all clean bufs").

However, SMP VM with 2 or more CPUs doesn't hang on reboot/power-off
according to our tests.

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

[Bug 227422] i386 mini-memstick 11-stable installer not recognized as bootable device on Lenovo x220

[bugzilla-noreply]

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

--- Comment #5 from Ed Maste  ---
Perhaps:

diff --git a/release/i386/make-memstick.sh b/release/i386/make-memstick.sh
index 1943e07942c1..1eb5d57942e3 100755
--- a/release/i386/make-memstick.sh
+++ b/release/i386/make-memstick.sh
@@ -36,10 +36,8 @@ makefs -B little -o label=FreeBSD_Install -o version=2
${2}.part ${1}
 rm ${1}/etc/fstab
 rm ${1}/etc/rc.conf.local

-mkimg -s gpt -b ${1}/boot/pmbr \
--p freebsd-boot:=${1}/boot/gptboot \
--p freebsd-ufs:=${2}.part \
--p freebsd-swap::1M \
+mkimg -s mbr -b ${1}/boot/mbr \
+-p freebsd:-"mkimg -s bsd -b ${1}/boot/boot -p freebsd-ufs:=${2}.part" \
 -o ${2}
 rm ${2}.part

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 200109] [PATCH] Minor EFI boot image enhancements

[bugzilla-noreply]

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

--- Comment #3 from Pedro F. Giffuni  ---
(In reply to Ed Maste from comment #1)

Well, it's rather silly but I wanted to keep some standard floppy size (perhaps
1.44M ?).

What would be really cool is if there were some way to install the Clover EFI
bootloader:

https://sourceforge.net/projects/cloverefiboot/

This would be really useful for those of us that still keep an old BIOS machine
with an under-utilized 3T HD and want to dual boot.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 200109] [PATCH] Minor EFI boot image enhancements

[bugzilla-noreply]

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

Pedro F. Giffuni  changed:

   What|Removed |Added

 Attachment #156626|0   |1
is obsolete||

--- Comment #2 from Pedro F. Giffuni  ---
Created attachment 192400
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=192400=edit
Small enhancements to the EFI image generation

Update for new path and other changes.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 184758] error in rtadvd.conf example

[bugzilla-noreply]

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

Oleksandr Tymoshenko  changed:

   What|Removed |Added

   Assignee|d...@freebsd.org |b...@freebsd.org
  Component|Documentation   |Manual Pages
 CC||d...@freebsd.org
 CC||go...@freebsd.org
  Component|Manual Pages|Documentation
   Assignee|b...@freebsd.org|d...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 155163] [patch] Add Recursive Functionality to setfacl(1)

[bugzilla-noreply]

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

Ed Maste  changed:

   What|Removed |Added

  Flags||mfc-stable10-,
   ||mfc-stable11?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 155163] [patch] Add Recursive Functionality to setfacl(1)

[bugzilla-noreply]

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

--- Comment #11 from commit-h...@freebsd.org ---
A commit references this bug:

Author: emaste
Date: Tue Apr 10 23:29:57 UTC 2018
New revision: 332396
URL: https://svnweb.freebsd.org/changeset/base/332396

Log:
  setfacl: add recursive functionality

  Add a -R option to setfacl to operate recursively on directories, along
  with the accompanying flags -H, -L, and -P (whose behaviour mimics
  chmod).

  A patch was submitted with PR 155163, but this is a new implementation
  based on comments raised in the Phabricator review for that patch
  (review D9096).

  PR:   155163
  Submitted by: Mitchell Horne 
  Reviewed by:  jilles
  MFC after:2 weeks
  Relnotes: Yes
  Sponsored by: The FreeBSD Foundation
  Differential Revision:https://reviews.freebsd.org/D14934

Changes:
  head/bin/setfacl/setfacl.1
  head/bin/setfacl/setfacl.c
  head/bin/setfacl/setfacl.h
  head/bin/setfacl/util.c

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

RE: [Bug 227404] UP FreeBSD VM always hangs on reboot since 20180329-r331740

[Bruce Evans]

On Tue, 10 Apr 2018, Dexuan Cui wrote:


From: Bruce Evans
Sent: Tuesday, April 10, 2018 00:45

On Tue, 10 Apr 2018 a bug that doesn't want repl...@freebsd.org wrote:

(The bug didn't even Cc freebsd-bugs for this followup.)


Thanks for the reminder! I Cc'd bugs@ just now.


--- Comment #4 from Dexuan Cui ---

...

I think I saw this a few months before that.

My only history of this is that I built a UP kernel on 17 Dec 2017 to see
if UP kernels had the bug.  So SMP kernels probably had the bug then.

Bruce


Here the bug is that UP FreeBSD VM hangs on reboot or power-off, and
I'm sure this recent patch (which was commited by Jeff on Mar 26) caused this 
bug:
https://github.com/freebsd/freebsd/commit/63a483ed5f4eaadb8979992c7a5de24c7a471c61
("Fix a bug introduced in r329612 that slowly invalidates all clean bufs").

However, SMP VM with 2 or more CPUs doesn't hang on reboot/power-off
according to our tests.


Actually, r329612 is what causes this bug.  I already did the bisection
to find almost this bug a couple of weeks ago.  The hang occurs on amd64
with 4 CPUs but not on amd64 with 8 CPUs or i386 with 4 or 8 CPUS.  I
just checked that it occurs on i386 with 1 CPU.  All on the same machine.
But r329611 doesn't hang for any of these cases.

XX From b...@optusnet.com.au Fri Mar 23 20:06:40 2018 +1100
XX Date: Fri, 23 Mar 2018 20:06:39 +1100 (EST)
XX From: Bruce Evans 
XX X-X-Sender: b...@besplex.bde.org
XX To: j...@freebsd.org
XX Subject: r329612 breaks sync for shutdown
XX Message-ID: <20180323192409.f1...@besplex.bde.org>
XX MIME-Version: 1.0
XX Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
XX Status: O
XX X-Status: 
XX X-Keywords: 
XX X-UID: 7935
XX 
XX r329612 (with or without later changes) sometimes (consistently in one

XX hardware coniguration) hangs in clean shutdowns by init:
XX 
XX i386 with 8 or 4 CPUs: it hasn't failed yet

XX amd64 with 8 CPUs:: it hasn't failed yet
XX and64 with 4 CPUs (by turning off HTT): it always or almost always hangs
XX 
XX The hang is usually in "Syncing disks, vnodes remaining... 0 ".  Less than

XX 10% of the time it hangs earlier in "Waiting ... for  syncer' ...".
XX It is just waiting for a wakeup that never arrives:  In the working case,
XX it prints about 2 more 0's, with about half a second between each.  If it
XX reaches the second 0, it always completes.
XX 
XX This is with SCHED_4BSD.  SCHED_ULE seems to work.  I recently looked for

XX missing wakeups and found some for idle threads in mwait.  This affects
XX both schedulers but fixing it makes little difference.  The bug is invariant
XX under other large changes in options and code.
XX 
XX XX KDB: enter: Break to debugger

XX XX [ thread pid 9 tid 100069 ]
XX XX Stopped at  kdb_enter+0x3a: movq$0,0x700c97(%rip)
XX XX db> ps
XX XX   pid  ppid  pgrp   uid  state   wmesg   wchan   cmd
XX XX18 0 0 0  DL  -   0x80be8462  [schedcpu]
XX XX17 0 0 0  DL  kpsusp  0xf80003e1a6e0  [vnlru]
XX XX16 0 0 0  RL  [syncer]
XX XX 9 0 0 0  RL  (threaded)  [bufdaemon]
XX XX 100059   RunQ[bufdaemon]
XX XX 100064   Run CPU 1   
[bufspacedaemon-0]
XX XX 100065   Run CPU 3   
[bufspacedaemon-1]
XX XX 100066   RunQ
[bufspacedaemon-2]
XX XX 100067   RunQ
[bufspacedaemon-3]
XX XX 100068   Run CPU 0   
[bufspacedaemon-4]
XX XX 100069   Run CPU 2   
[bufspacedaemon-5]
XX XX 100070   CanRun  
[bufspacedaemon-6]
XX XX 8 0 0 0  DL  (threaded)  [pagedaemon]
XX XX 100058   D   psleep  0x80c7b82d  [pagedaemon]
XX XX 100062   D   launds  0x80c7b834  [laundry: 
dom0]
XX XX 100063   D   umarcl  0x80676967  [uma]
XX XX 7 0 0 0  DL  -   0x80c73dd4  [soaiod4]
XX XX 6 0 0 0  DL  -   0x80c73dd4  [soaiod3]
XX XX 5 0 0 0  DL  -   0x80c73dd4  [soaiod2]
XX XX --More--4 0 0 0  DL  -   
0x80c73dd4  [soaiod1]
XX XX15 0 0 0  DL  cooling 0xf8000186a758  
[acpi_cooling1]
XX XX14 0 0 0  DL  tzpoll  0x80aaa110  
[acpi_thermal]
XX XX 3 0 0 0  DL  -   0x80aab218  
[rand_harvestq]
XX XX13 0 0 0  DL  (threaded)  [usb]
XX XX 100023   D   -   0xfe00839d4460  [usbus0]
XX XX 100024   D   -   0xfe00839d44b8  

RE: [Bug 227404] UP FreeBSD VM always hangs on reboot since 20180329-r331740

[Dexuan Cui via freebsd-bugs]

> From: Bruce Evans 
> Sent: Tuesday, April 10, 2018 13:09
> > Here the bug is that UP FreeBSD VM hangs on reboot or power-off, and
> > I'm sure this recent patch (which was committed by Jeff on Mar 26) caused
> > this bug:
> > r331561:Fix a bug introduced in r329612 that slowly invalidates all clean 
> > bufs.
> >
> > However, SMP VM with 2 or more CPUs doesn't hang on reboot/power-off
> > according to our tests.
> 
> Actually, r329612 is what causes this bug.  I already did the bisection
> to find almost this bug a couple of weeks ago.  The hang occurs on amd64
> with 4 CPUs but not on amd64 with 8 CPUs or i386 with 4 or 8 CPUS.  I
> just checked that it occurs on i386 with 1 CPU.  All on the same machine.
> But r329611 doesn't hang for any of these cases.

So, it looks to me that: r329612 introduced a hang issue, so Jeff made r331561,
trying to fix the issue, but it looks the issue is not completely fixed (at 
least for me).

I didn't test r329612.

We noticed our amd64 VM (which has a single CPU) hung . The VM kernel was 
built with yesterday's latest kernel code + the default GENERIC kernel config.

However, using the same kernel binary, if we configure 2 or more CPUs
to the VM, the VM doesn't hang on reboot.

If I use the latest code but manually remove the changes made by r331561, 
the hang issue with our single-CPU VM will go away.

I hope the info is helpful.
 
> I still think there is an older bug, but now think it is related.  I
> only tested with SCHED_4BSD.  For SCHED_4BSD, I suspect that the bug
> is from pinning a thread to a CPU and then stopping that CPU.  Pure
> UP has no problems since pinning is null for it.  SCHED_4BSD has especially
> special handing for SMP (a separate runq for each CPU.  I have been
> modifying
> SCHED_4BSD and the separate queues mostly get in the way).
> 
> Bruce

I always use the default GENERIC kernel options, so I guess I'm using 
SCHED_4BSD(?)..

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

[Bug 155163] [patch] Add Recursive Functionality to setfacl(1)

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

   Keywords||patch

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 227404] UP FreeBSD VM always hangs on reboot since 20180329-r331740

[bugzilla-noreply]

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

--- Comment #5 from Dexuan Cui  ---
(In reply to Dexuan Cui from comment #4)
When the bug reproduces, the log is:

Stopping cron.
Stopping sshd.
appending output to nohup.out
Stopping devd.
Writing entropy file:.
Writing early boot entropy file:.
Terminated
.
Apr 10 14:46:40 decui-b11 syslogd: exiting on signal 15
Waiting (max 60 seconds) for system process `vnlru' to stop... done
Waiting (max 60 seconds) for system process `bufdaemon' to stop... done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining... 4
(It hangs here)


After I revert 63a483ed5f4eaadb8979992c7a5de24c7a471c61, the bug can't
reproduce, despite the messages:

Apr 10 14:28:44 decui-b11 syslogd: exiting on signal 15
Waiting (max 60 seconds) for system process `vnlru' to stop... done
Waiting (max 60 seconds) for system process `bufdaemon' to stop... done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining... 4 1 0 done
All buffers synced.
lock order reversal:
 1st 0xf80008533ba8 ufs (ufs) @ /root/bsd.git/sys/kern/vfs_mount.c:1335
 2nd 0xf800085d0428 syncer (syncer) @
/root/bsd.git/sys/kern/vfs_subr.c:2732
stack backtrace:
#0 0x80bccfa3 at witness_debugger+0x73
#1 0x80bcce24 at witness_checkorder+0xe34
#2 0x80b3bb9b at lockmgr_lock_fast_path+0x17b
#3 0x8119d069 at VOP_LOCK1_APV+0xd9
#4 0x80c488a6 at _vn_lock+0x66
#5 0x80c379a7 at vputx+0x157
#6 0x80c2f7d9 at dounmount+0x4d9
#7 0x80c3919b at vfs_unmountall+0x6b
#8 0x80c14a25 at bufshutdown+0x2c5
#9 0x80b66d7a at kern_reboot+0x21a
#10 0x80b66b09 at sys_reboot+0x3a9
#11 0x8102706b at amd64_syscall+0x79b
#12 0x8100191d at fast_syscall_common+0x101
lock order reversal:
 1st 0xf80008533ba8 ufs (ufs) @ /root/bsd.git/sys/kern/vfs_mount.c:1335
 2nd 0xf800085d07e8 devfs (devfs) @
/root/bsd.git/sys/ufs/ffs/ffs_vfsops.c:1371
stack backtrace:
#0 0x80bccfa3 at witness_debugger+0x73
#1 0x80bcce24 at witness_checkorder+0xe34
#2 0x80b3bb9b at lockmgr_lock_fast_path+0x17b
#3 0x8119d069 at VOP_LOCK1_APV+0xd9
#4 0x80c488a6 at _vn_lock+0x66
#5 0x80e67a93 at ffs_flushfiles+0x93
#6 0x80e4adf2 at softdep_flushfiles+0x82
#7 0x80e6a147 at ffs_unmount+0x77
#8 0x80c2f819 at dounmount+0x519
#9 0x80c3919b at vfs_unmountall+0x6b
#10 0x80c14a25 at bufshutdown+0x2c5
#11 0x80b66d7a at kern_reboot+0x21a
#12 0x80b66b09 at sys_reboot+0x3a9
#13 0x8102706b at amd64_syscall+0x79b
#14 0x8100191d at fast_syscall_common+0x101
Uptime: 2m50s
acpi0: Powering system off



BTW, when the patch is reverted, I occasionally get this when the VM boots, but
I guess that's a different issue:

(da1:storvsc2:0:0:0): storvsc inquiry (6) [0 b2 0 4 1 ... ]
da2 at storvsc2 bus 0 scbus4 target 0 lun 2
da2:  Fixed Direct Access SPC-3 SCSI device
da2: 300.000MB/s transfers
da2: Command Queueing enabled
da2: 51200MB (104857600 512 byte sectors)
s_debugger+0x73
#1 0x80(da2:storvsc2:0:0:2): storvsc inquiry (6) [0 b2 0 4 1 ... ]
(da1:storvsc2:0:0:0): storvsc inquiry (5) [0 b0 0 3c 0 ... ]
bce381 at witness_warn+0x461
#2 0x81026273 at trap_pfa(da2:storvsc2:0:0:2): storvsc inquiry (5) [0
b0 0 3c 0 ... ]
(da1:storvsc2:0:0:0): storvsc inquiry (5) [0 b1 0 3c 0 ... ]
da1: Delete methods: 
ult+0x53
#3 0x81025a72 (da2:storvsc2:0:0:2): storvsc inquiry (5) [0 b1 0 3c 0
... ]
da2: Delete methods: 
at trap+0x2f2
#4 0x810010cc at calltrap+0x8
#5 0x80c1af78 at vfs_vmio_unwire+0x78
#6 0x80c16350 at bGEOM: new disk da2
relse+0x3c0
#7 0x80e6af3a at ffs_use_bread+0x9a
#8 0x80e6659c at ffs_sbget+0x8c
#9 0x80e69213 at ffs_mount+0xe03
#10 0x80c2e449 at vfs_domount+0x719
#11 0x80c2d727 at vfs_donmount+0x7f7
#12 0x80c30a32 at kernel_mount+0x62
#13 0x80c32ddd at parse_mount+0x43d
#14 0x80c3150c at vfs_mountroot+0x68c
#15 0x80afe567 at start_init+0x27
#16 0x80b277b4 at fork_exit+0x84
#17 0x81001dee at fork_trampoline+0xe


Fatal trap 12: page fault while in kernel mode
cpuid = 12; apic id = 0c
fault virtual address   = 0x0
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80ea6081
stack pointer   = 0x28:0xfe002d0b1140
frame pointer   = 0x28:0xfe002d0b1150
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 = 1 (kernel)
[ thread pid 1 tid 12 ]
Stopped at  _vm_page_deactivate+0xb1:   cmpq%rcx,(%rax)
db> bt
Tracing pid 1 tid 12 td 0xf800032e0560

Re: [Bug 227404] UP FreeBSD VM always hangs on reboot since 20180329-r331740

[Bruce Evans]

On Tue, 10 Apr 2018 a bug that doesn't want repl...@freebsd.org wrote:


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227404
...
--- Comment #1 from Dexuan Cui  ---
When the issue happens, the cpu utilization of the UP VM is 100%.

While we're trying to find the first bad revision, it would be great if
somebody can report if the issue also happens to bare metal or other
hypervisors.


This has been happening for at least several months on real hardware too.
SMP kernels hang on a 1-CPU system and on an 8-CPU systems with all except
1 CPU turned off in the BIOS.  They don't hang on the 8-CPU system with at
least 2 CPUs turned on.  UP kernels don't hang.  I use SCHED_4BSD.
SCHED_ULE is apparently not much different for this.

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

[Bug 227408] apropos(1) doesn't sort

[bugzilla-noreply]

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

Bug ID: 227408
   Summary: apropos(1) doesn't sort
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: tr...@freebsd.org

It appears that apropos(1) fails to sort.  It kind of does, but in a funny way.
 You can see it with "apropos -s 9 map", and look for eg "pmap" in the output.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 227409] mandoc(1) renders ".Aq" as something that looks weird in vt(4)

[bugzilla-noreply]

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

Bug ID: 227409
   Summary: mandoc(1) renders ".Aq" as something that looks weird
in vt(4)
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: tr...@freebsd.org

mandoc(1) renders .Aq and .Ao as something that renders as a square (missing
glyph, I suppose) in vt(4) consoles.  To reproduce: switch to a virtual
console, log in, do "man mdoc", search for Ao and see the example output right
next to it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: [Bug 227404] UP FreeBSD VM always hangs on reboot since 20180329-r331740

[Bruce Evans]

On Tue, 10 Apr 2018 a bug that doesn't want repl...@freebsd.org wrote:

(The bug didn't even Cc freebsd-bugs for this followup.)


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



--- Comment #4 from Dexuan Cui  ---
I think the first bad patch is this one:
https://github.com/freebsd/freebsd/commit/63a483ed5f4eaadb8979992c7a5de24c7a471c61
(Fix a bug introduced in r329612 that slowly invalidates all clean bufs.):

Today's
https://github.com/freebsd/freebsd/commit/66e8725e8d24141506bc4f458ec7d1a51e86304c
is broken, but if I revert 63a483ed5f4eaadb8979992c7a5de24c7a471c61, the bug
can not reproduce.

Cc bde & jeff.


I think I saw this a few months before that.

My only history of this is that I built a UP kernel on 17 Dec 2017 to see
if UP kernels had the bug.  So SMP kernels probably had the bug then.

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

[Bug 227409] mandoc(1) renders ".Aq" as something that looks weird in vt(4)

[bugzilla-noreply]

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

Ed Maste  changed:

   What|Removed |Added

 CC||ema...@freebsd.org

--- Comment #1 from Ed Maste  ---
I cannot reproduce this; for me it renders correctly as:
Aq, Ao, Ac   enclose in angle brackets: 

45f0  20 20 5f 08 41 5f 08 71  2c 20 5f 08 41 5f 08 6f  |  _.A_.q, _.A_.o|
4600  2c 20 5f 08 41 5f 08 63  20 20 20 20 20 20 20 65  |, _.A_.c   e|
4610  6e 63 6c 6f 73 65 20 69  6e 20 61 6e 67 6c 65 20  |nclose in angle |
4620  62 72 61 63 6b 65 74 73  3a 20 3c 74 65 78 74 3e  |brackets: |
4630  0a 20 20 20 20 20 5f 08  45 5f 08 6f 2c 20 5f 08  |. _.E_.o, _.|

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 227436] increasing kern.maxswzone does nothing

[bugzilla-noreply]

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

Bug ID: 227436
   Summary: increasing kern.maxswzone does nothing
   Product: Base System
   Version: 11.1-STABLE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: cur...@ipv6.occnc.com

Created attachment 192425
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=192425=edit
patch to sys/vm/swap_pager.c (see comments for description)

On current and on 11.1 when using a large amount of swap, increasing
kern.maxswzone does not allow more swap to be used as it used to in 11.0.

A patch is attached which has been tested on AMD64 and ARM64 kernels using 11.1
stable and current.  It does the following:

1.  If maxswzone is set to less than the system guess (based on RAM), then
reduce maxswzone as specified (current behaviour).

2.  There is a conditional that could be removed that caps the increase in
maxswzone to 8 times the guess based on RAM (lots of swap, but lots is needed
for small ARM stuff that has 512MB or 1GB RAM.  Also had to increase
kern.maxswzone on some of my AMD64 servers with 8GB RAM).

3.  An increase is made to the effective maxswzone value used (n in the code)
subject to the above conditional (which could be removed).

4.  Change a printf statement to give swap sizes in pages and MB when
kern.maxswzone is too small for the amount of swap.

5.  Add printf indicating the minimum value of kern.maxswzone that will quiet
the warning (and presumably allow that amount of swap to be used).

6.  Add a conditional that catches the case where the guess at the size of
struct swblk in sys/i386/include/param.h is wrong.  This code was removed in
other architectures so affects i386 only.  I added this code temporarily to
amd64 to test.

I've been using this patch with no adverse affect on multiple production
servers and vm for a few weeks.  Given that all it does is allow increase in
kern.maxswzone to take effect, it should be safe and should go into 11.2, but
at least go into 12.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"