[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 #3 from Andriy Gapon  ---
(In reply to Dexuan Cui from comment #0)
I have observed a similar (perhaps the same issue) on real multi-core hardware
but with the SMP kernel (GENERIC) when all APs were disabled via hints
(hint.lapic.%d.disabled=1).

The reboot got stuck and a thread doing it was in this state:
db> bt
Tracing pid 1 tid 12 td 0xf80003230560
sched_switch() at sched_switch+0x95c/frame 0xfe00213b9880
mi_switch() at mi_switch+0x188/frame 0xfe00213b98b0
sleepq_switch() at sleepq_switch+0x10d/frame 0xfe00213b98f0
sleepq_timedwait() at sleepq_timedwait+0x50/frame 0xfe00213b9930
_sleep() at _sleep+0x2fa/frame 0xfe00213b99d0
kproc_suspend() at kproc_suspend+0x9a/frame 0xfe00213b9a00
kproc_shutdown() at kproc_shutdown+0x4e/frame 0xfe00213b9a20
kern_reboot() at kern_reboot+0x19e/frame 0xfe00213b9a60
sys_reboot() at sys_reboot+0x3ab/frame 0xfe00213b9ac0
amd64_syscall() at amd64_syscall+0x79b/frame 0xfe00213b9bf0
fast_syscall_common() at fast_syscall_common+0x105/frame 0xfe00213b9bf0

I didn't examine other threads much.

-- 
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 227406] man zfs need correcting on import to FreeBSD, as some behaviours differ from its source OS

[bugzilla-noreply]

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

--- Comment #1 from Stilez  ---
clarification to OP, 3rd para, "the setuid bit acts on files and dirs if the
file system supports it" is referencing the chmod 4000 bit, not the zfs
property of the same name. The issue is that zfs only supports it partially
(files but not dirs) but its man page doesn't say so.

-- 
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 227407] [feature request] make zfs "setuid" property act on dirs as well as files

[bugzilla-noreply]

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

Bug ID: 227407
   Summary: [feature request] make zfs "setuid" property act on
dirs as well as files
   Product: Base System
   Version: 11.1-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: stil...@gmail.com

Currently the zfs filesystem's "setuid" property is limited to files - it has
no effect on directories within a zfs dataset. (crossref: man page error, bug
#227406)

setuid on directories is extremely useful in many scenarios, and for UFS at
least is the standard way on FreeBSD to mandate+enforce ownership (including
ownership inheritance on new objects) within a file system or directory path.

Lacking zfs setuid support on directories, there is no way to achieve this
AFAIK for file systems/directory paths on zfs.

Can the setuid property be enhanced for zfs, so that it does permit
ownership/inheritance control on directories as well?

-- 
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 227407] [feature request] make zfs "setuid" property act on dirs as well as files

[bugzilla-noreply]

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

Stilez  changed:

   What|Removed |Added

   Severity|Affects Only Me |Affects Some People

-- 
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 227406] man zfs need correcting on import to FreeBSD, as some behaviours differ from its source OS

[bugzilla-noreply]

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

Stilez  changed:

   What|Removed |Added

Summary|man zfs describes effect of |man zfs need correcting on
   |some flags on   |import to FreeBSD, as some
   |solaris/classic unix, need  |behaviours differ from its
   |correcting for differences  |source OS
   |on import to FreeBSD|

-- 
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 227406] man zfs describes effect of some flags on solaris/classic unix, need correcting for differences on import to FreeBSD

[bugzilla-noreply]

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

Bug ID: 227406
   Summary: man zfs describes effect of some flags on
solaris/classic unix, need correcting for differences
on import to FreeBSD
   Product: Documentation
   Version: Latest
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: Manual Pages
  Assignee: b...@freebsd.org
  Reporter: stil...@gmail.com
CC: d...@freebsd.org

The zfs man page has been imported from its source unix
(illumos/openzfs/solaris/classical unix of some kind) without correcting for
discrepancies between the source OS described and FreeBSD. It therefore
misleads about the scope of the setuid flag on FreeBSD.

"man zfs" -> "setuid=on" property states that this property "controls whether
the set-UID bit is respected for the file system". There are no stated
qualifiers/limitations. 

On a classical unix this may be a correct description but on FreeBSD the setuid
bit acts on files **and dirs** "if the file system supports it", which "man
zfs" implies it does (ref: man chmod).

So a plain reading of man zfs is that setting this property will affect files
and dirs. This is not correct *for FreeBSD* even if common on other UNIXes.


Correction required:

"setuid = on | off : Controls whether the set-UID bit is respected for **files
on** the file system. **The property has no effect on directories on the file
system**.  The default value is on."


Current wording (incorrect):

"setuid = on | off : Controls whether the set-UID bit is respected for the file
system. The default value is on."


Issue identified via FreeBSD-fs mailing list discussion.

-- 
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 #2 from Dexuan Cui  ---
When the hang issue happens, the last serial message is the line
"Syncing disks, vnodes remaining... 4 ".

Later I sent an NMI interrupt to the VM by Hyper-V PowerShell cmdlet, and the
kernel printed out the later lines showing the call-stack.

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

   Hardware|Any |amd64
   Severity|Affects Only Me |Affects Some People

--- 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.

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

Ed Maste  changed:

   What|Removed |Added

 CC||ema...@freebsd.org

--- Comment #1 from Ed Maste  ---
WRT the FAT image, 800K is indeed too small, but what we really need to do is
start running newfs_msdos on the EFI partition at install time so that it's
200MB and has enough room for dual-boot cases etc.

This should really happen for 12.0, and I'd rather avoid proliferating
different sizes.

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

Bug ID: 227404
   Summary: UP FreeBSD VM always hangs on reboot since
20180329-r331740
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: de...@microsoft.com

It looks on Hyper-V the issue only happens to UP VM (SMP VM is good), but the
VM hangs in the generic FreeBSD kernel code, so I suspect the issue should
reproduce on bare metal as well.

More info:
FreeBSD-12.0-CURRENT-amd64-20180322-r331345-disc1.iso is good, but
FreeBSD-12.0-CURRENT-amd64-20180329-r331740-disc1.iso is broken.


These are the serial messages:

Tue Apr 10 01:52:02 CST 2018

FreeBSD/amd64 (decui-b11) (ttyu0)

login: Stopping cron.
Stopping sshd.
appending output to nohup.out
Stopping devd.
Writing entropy file:.
Writing early boot entropy file:.
Terminated
.
Apr 10 01:52:10 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 NMI ISA 0, EISA ff
NMI/cpu0 ... going to debugger
[ thread pid 18 tid 100055 ]
Stopped at  witness_lock+0x1ae: popq%rbp
db> bt
Tracing pid 18 tid 100055 td 0xf8000b052000
witness_lock() at witness_lock+0x1ae/frame 0xfe0026553930
sched_add() at sched_add+0xe3/frame 0xfe0026553970
setrunnable() at setrunnable+0x8f/frame 0xfe0026553990
sleepq_broadcast() at sleepq_broadcast+0xe8/frame 0xfe00265539d0
wakeup() at wakeup+0x1d/frame 0xfe00265539f0
kproc_suspend_check() at kproc_suspend_check+0x58/frame 0xfe0026553a20
buf_daemon() at buf_daemon+0x11a/frame 0xfe0026553a70
fork_exit() at fork_exit+0x84/frame 0xfe0026553ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe0026553ab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
db>

-- 
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 #10 from Ed Maste  ---
Updated patch in review at https://reviews.freebsd.org/D14934

-- 
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 227403] [ACPI] [nvidia] [drm] NVRM: rm_init_adapter() failed

[bugzilla-noreply]

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

Bug ID: 227403
   Summary: [ACPI] [nvidia] [drm] NVRM: rm_init_adapter() failed
   Product: Base System
   Version: CURRENT
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: kjcamannli...@gmail.com

I am testing FreeBSD on a new model of ThinkPad (T480) that was just released
three months ago.

Some variants of this model (and the similar T480s) have only Kaby Lake
integrated graphics, whereas others include a GeForce MX150.

The two GPUs in my system are:

- Integrated UHD Graphics 620 (on the i7-8650U, in my case)
- NVIDIA GeForce MX150 [reports as Lenovo GP108M]

I am using:

FreeBSD-12.0-CURRENT-amd64-20180322-r331345 snapshot (GENERIC kernel)
drm-next-kmod from ports for Intel driver
nvidia-driver-390 from ports

Both video drivers successfully attach to their devices. The i915 device works,
but the nvidia device does not. Whenever the adapter is initialized for any
reason (e.g., by `nvidia-xconfig --query-gpu-info` or `nvidia-debugdump -l`)
this appears in dmesg:

NVRM: failed to copy vbios to system memory.
NVRM: RmInitAdapter failed! (0x30:0x:662)
nvidia1: NVRM: rm_init_adapter() failed!

I filed this under ACPI because this error has appeared many times in the past
in both Linux and FreeBSD, and the resolution often has something to do with
the ACPI, and something looks "off" with ACPI here well.

devinfo -v shows the devices like this:

intel) vgapci0 pnpinfo vendor=0x8086 device=0x5917 subvendor=0x17aa
subdevice=0x225e class=0x03 at slot=2 function=0 dbsf=pci0:0:2:0
handle=\_SB_.PCI.GFX0

nvidia) vgapci1 pnpinfo vendor=0x10de device=0x1d10 device=0x17aa
subvendor=0x17aa subdevice=0x225e class0x030200 at slot=0 funcition=0
dbsf=pci0:1:0:0 handle=\_SB_.PCI0.RP01.PXSX

Note that nvidia card's ACPI bus location is listed as `\_SB_PCI0.RP01.PXSX`.
In an Arch Linux system I dual-boot with, the NVIDIA card works correctly and
the ACPI firmware node is reported as `\_SB_.PCI0.RP01.PEGP` (where I guess
PEGP means something like PCI-Express Graphics Port). By "firmware node", I
mean the sysfs value defined here:
https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-devices-firmware_node

Is the problem that the system is "using" the wrong ACPI object to poke at the
vbios area? These two ACPI objects (PXSX and PEGP) appear in two different SSDT
tables -- PXSX appears in the table that occurs first in an acpidump. The
second one (PEGP) is incredibly more complex, and so probably contains most of
the interesting functionality. I tried to do more research before posting this
but I find ACPI completely bewildering.

Please let me know what other information to attach to this report.

-- 
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 227388] [cpufreq] [patch] Most newer Pentium M ULV frequency tables doesn't finished correctly

[bugzilla-noreply]

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

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 227388] [cpufreq] [patch] Most newer Pentium M ULV frequency tables doesn't finished correctly

[bugzilla-noreply]

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

Bug ID: 227388
   Summary: [cpufreq] [patch] Most newer Pentium M ULV frequency
tables doesn't finished correctly
   Product: Base System
   Version: 11.1-STABLE
  Hardware: i386
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: xde...@meta.ua

Created attachment 192359
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=192359=edit
est.c patch

I've installed FreeBSD 11.1 onto Fujitsu Siemens P7120 with Pentium M 753 ULV
1.2GHz inside. In result: system refused to run powerd, sometime system crashes
(mostly after executing "reboot" or "sysctl -a"), messages "tsc_levels_changed:
no max freq found" and "cpufreq: need to increase CF_MAX_LEVELS" are appeared
on console. "sysctl dev.est.0.freq_settings" output:

dev.est.0.freq_settings: 1200/-1 1100/-1 1000/-1 900/-1 800/-1 600/-1 1200/-1
11
00/-1 1000/-1 900/-1 800/-1 600/-1 1200/-1 1100/-1 1000/-1 900/-1 800/-1 600/-1
1200/-1 1100/-1 1000/-1 900/-1 800/-1 600/-1 1200/-1 1100/-1 1000/-1 900/-1
800/
-1 600/-1 1100/-1 1000/-1 900/-1 800/-1 600/-1 1100/-1 1000/-1 900/-1 800/-1
600
/-1 1100/-1 1000/-1 900/-1 800/-1 600/-1 1100/-1 1000/-1 900/-1 800/-1 600/-1
11
00/-1 1000/-1 900/-1 800/-1 600/-1 1100/-1 1000/-1 900/-1 800/-1 600/-1 1100/-1
1000/-1 900/-1 800/-1 600/-1

As turned out, some frequency tables, including one for "Pentium M 753 ULV
1.2GHz" have no finalization line "FREQ_INFO(   0,0, 1)".

After applying patch - all mentioned symptomps are disappeared.

-- 
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 168962] cp(1) & mv(1) pages don't mention ACLs or extended attributes

[bugzilla-noreply]

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

Oleksandr Tymoshenko  changed:

   What|Removed |Added

 CC||d...@freebsd.org
  Component|Documentation   |Manual Pages
   Assignee|d...@freebsd.org |b...@freebsd.org
 Status|In Progress |Closed
 Resolution|--- |FIXED
 CC||go...@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"