[Bug 220024] head -r319991 clang powerpc64 and powerpc toolchains (cross build target): boot1.o: In function `fsread_size': undefined reference to `__udivdi3' (INO64 involved)

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

   Keywords||regression
   Assignee|freebsd-bugs@FreeBSD.org|freebsd-toolchain@FreeBSD.o
   ||rg

-- 
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 220032] [if_alc] sys/dev/alc/if_alc.c: sleep-under-mutex bugs

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|freebsd-...@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 220024] head -r319991 clang powerpc64 and powerpc toolchains (cross build target): boot1.o: In function `fsread_size': undefined reference to `__udivdi3' (INO64 involved)

[bugzilla-noreply]

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

--- Comment #5 from Mark Millard  ---
(In reply to Mark Millard from comment #4)

I should have noted up front that:

/usr/src/sys/boot/powerpc/boot1.chrp/boot1.c

does:

#include "ufsread.c"

and that is the context of the __udivdi3
use that is rejected at link time when
clang is used to buildworld for powerpc
or powerpc64.



As for potential INO64 issues beyond
__udivdi3 use and needin got have it
available for linking:

My original comment #4 might really trace
back to boot1.c needing to be different
even if ufsread.c stays the same.

-- 
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 220033] [if_ixgb] sys/dev/ixgb/if_ixgb.c: a sleep-under-mutex bug in ixge_get_buf

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|freebsd-...@freebsd.org
 CC||sbr...@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 220024] head -r319991 clang powerpc64 and powerpc toolchains (cross build target): boot1.o: In function `fsread_size': undefined reference to `__udivdi3' (INO64 involved)

[bugzilla-noreply]

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

Mark Millard  changed:

   What|Removed |Added

Summary|head -r319991 clang |head -r319991 clang
   |powerpc64 and powerpc   |powerpc64 and powerpc
   |toolchains (cross build |toolchains (cross build
   |target): boot1.o: In|target): boot1.o: In
   |function `fsread_size': |function `fsread_size':
   |undefined reference to  |undefined reference to
   |`__udivdi3' |`__udivdi3' (INO64
   ||involved)

--- Comment #4 from Mark Millard  ---
Turns out clang is generating the __udivdi3
references because of the INO64 changes being
involved in fsread_size --at least if I
understand right.

And that explains why this was not a problem
in the likes of -r317820 (before INO64).

For reference: part of a note that I sent out
on the lists. . .

buildworld via clang for powerpc64 and powerpc fails for lack of
`__udivdi3' referenced in sys/boot/common/ufsread.c fsread_size
code. But this lead to me looking around and I found a conceptually
separate possible issue. . .

sys/sys/_types.h :

typedef __uint64_t  __ino_t;/* inode number */

# find /usr/src/sys/ -exec grep __ino_t {} \; -print | more
typedef __ino_t ino_t;
/usr/src/sys/sys/stat.h
typedef __ino_t ino_t;  /* inode number */
/usr/src/sys/sys/types.h
typedef __uint64_t  __ino_t;/* inode number */
/usr/src/sys/sys/_types.h
typedef __ino_t ino_t;
/usr/src/sys/sys/dirent.h


sys/boot/common/ufsread.c :

. . .
#include 
#include 
#include 
. . .
typedef uint32_tufs_ino_t;
. . .

Note the 32-bit type above. The headers included
have use of the 64-bit ino_t type as well, for
example:

sys/ufs/ufs/diniode.h :

. . .
#define UFS_ROOTINO ((ino_t)2)
. . .
#define UFS_WINO((ino_t)1)
. . .

sys/ufs/ffs/fs.h :

. . .
#define ino_to_cg(fs, x)(((ino_t)(x)) / (fs)->fs_ipg)
#define ino_to_fsba(fs, x)  \
   ((ufs2_daddr_t)(cgimin(fs, ino_to_cg(fs, (ino_t)(x))) + \
   (blkstofrags((fs), ino_t)(x)) % (fs)->fs_ipg) / INOPB(fs))
#define ino_to_fsbo(fs, x)  (((ino_t)(x)) % INOPB(fs))
. . .


I believe the powerpc64/powerpc issue
gives evidence of ino_t being used in
addition to ufs_ino_t in
sys/boot/common/ufsread.c 's fsread_size .

-- 
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 217100] POSIX AIO intermittently returns EOPNOTSUPP

[bugzilla-noreply]

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

Jung-uk Kim  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 CC||j...@freebsd.org
 Status|New |Closed

--- Comment #2 from Jung-uk Kim  ---


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

-- 
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 201898] [bsdinstall] UEFI boot partition parameters

[bugzilla-noreply]

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

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

Author: emaste
Date: Fri Jun 16 18:58:48 UTC 2017
New revision: 320007
URL: https://svnweb.freebsd.org/changeset/base/320007

Log:
  bsdinstall: use consistent EFI configuration across platforms

  - increase arm64 EFI partition to 200M, as x86
  - use EFI_BOOTPART_SIZE and EFI_BOOTPART_PATH macros on x86
  - increase ZFS EFI partition to 200M

  PR:   201898
  Reviewed by:  allanjude, manu
  MFC after:3 days
  Sponsored by: The FreeBSD Foundation
  Differential Revision:https://reviews.freebsd.org/D11239

Changes:
  head/usr.sbin/bsdinstall/partedit/partedit_arm64.c
  head/usr.sbin/bsdinstall/partedit/partedit_x86.c
  head/usr.sbin/bsdinstall/scripts/zfsboot

-- 
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 219846] [panic] [kevent] mutex nm_kn_lock not owned, netmap with INVARIANTS+WITNESS

[bugzilla-noreply]

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

Harald Schmalzbauer  changed:

   What|Removed |Added

Summary|[panic] mutex nm_kn_lock|[panic] [kevent] mutex
   |not owned, netmap LOR   |nm_kn_lock not owned,
   ||netmap with
   ||INVARIANTS+WITNESS

-- 
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 219846] [panic] mutex nm_kn_lock not owned, netmap LOR

[bugzilla-noreply]

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

--- Comment #1 from Harald Schmalzbauer  ---
Vincezzo Maffione already tried to find a solution, but he mentioned that help
from kevent experts was needed.
(You can find the discussion and tested fixes here
https://github.com/luigirizzo/netmap/issues/318)

Thanks,

-harry

-- 
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 209816] [lor] lock order reversal with devfs, tmpfs and ufs

[bugzilla-noreply]

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

m...@netfence.it changed:

   What|Removed |Added

 CC||m...@netfence.it

--- Comment #1 from m...@netfence.it ---
Hello.

I've just seen the same on a 10.3p18/amd64:

lock order reversal:
1st 0xf803b3908a28 tmpfs (tmpfs) @ /usr/src/sys/kern/vfs_mount.c:848
2nd 0xf803b3908c98 ufs (ufs) @ /usr/src/sys/fs/nullfs/null_vnops.c:670
KDB: stack backtrace:
#0 0x804c72b0 at kdb_backtrace+0x60
#1 0x804e7204 at witness_checkorder+0xe24
#2 0x80468a79 at __lockmgr_args+0x9d9
#3 0x806b2162 at ffs_lock+0x92
#4 0x8077ad5c at VOP_LOCK1_APV+0xfc
#5 0x803c2dd0 at null_lock+0xe0
#6 0x8077ad5c at VOP_LOCK1_APV+0xfc
#7 0x80547492 at _vn_lock+0xd2
#8 0x803c2010 at nullfs_root+0x50
#9 0x805306d8 at vfs_donmount+0x13b8
#10 0x8052f2ff at sys_nmount+0x4f
#11 0x80712f3c at amd64_syscall+0x2ac
#12 0x806f6b0b at Xfast_syscall+0xfb
lock order reversal:
1st 0xf803a337c2d8 tmpfs (tmpfs) @ /usr/src/sys/kern/vfs_mount.c:848
2nd 0xf8024f106a28 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2253
KDB: stack backtrace:
#0 0x804c72b0 at kdb_backtrace+0x60
#1 0x804e7204 at witness_checkorder+0xe24
#2 0x80468a79 at __lockmgr_args+0x9d9
#3 0x80528a5c at vop_stdlock+0x3c
#4 0x8077ad5c at VOP_LOCK1_APV+0xfc
#5 0x80547492 at _vn_lock+0xd2
#6 0x805387e7 at vget+0x67
#7 0x8038e8cd at devfs_allocv+0xfd
#8 0x8038e353 at devfs_root+0x43
#9 0x805306d8 at vfs_donmount+0x13b8
#10 0x8052f2ff at sys_nmount+0x4f
#11 0x80712f3c at amd64_syscall+0x2ac
#12 0x806f6b0b at Xfast_syscall+0xfb



The second one looks like and old friend:
http://sources.zabbadoz.net/freebsd/lor/280.html

I couldn't fine the first one on that list, though.



This happened while running Poudriere on a full UFS+SU (no ZFS) system.
In fact Poudriere has brough my box to a complete hang several times (forcing
an hardware reset) and that's why I enabled WITNESS, INVARIANTS, etc...
After such an hang, the system is very likely to panic over and over again
until I boot into single user mode and "fsck -y" every filesystem (including a
full fsck after replaying the journal on UFS+SU+J partitions).



On another run only the second LOR showed up without the first.

-- 
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 220037] [vfs] sys/kern/vfs_bio.c: a sleep-under-rwlock bug in getblk

[bugzilla-noreply]

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

Mark Johnston  changed:

   What|Removed |Added

 CC||ma...@freebsd.org
 Status|New |Closed
 Resolution|--- |Not A Bug

--- Comment #1 from Mark Johnston  ---
The bufobj lock is released in getblk() when the (sleepable) buf lock is
acquired with BUF_TIMELOCK().

-- 
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 220023] procstat -L only works with corefiles ...?

[bugzilla-noreply]

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

--- Comment #1 from Mark Johnston  ---
procstat -L shows information about a process' exit, so it's not expected to
work with live processes. We should update the man page and error message to
make this clear.

-- 
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 204265] Add fallback PSCI reboot to cpu_reset.

[bugzilla-noreply]

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

Ed Maste  changed:

   What|Removed |Added

 Status|Open|In Progress
   Assignee|freebsd-bugs@FreeBSD.org|and...@freebsd.org

--- Comment #3 from Ed Maste  ---
Andy this is now fixed?

-- 
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 201898] [bsdinstall] UEFI boot partition parameters

[bugzilla-noreply]

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

Ed Maste  changed:

   What|Removed |Added

 Status|New |In Progress

--- Comment #1 from Ed Maste  ---
This was done in r302145 - the partition size is 200M. This is prior to the
stable/11 branch, so this is the case from 11.0 on. I will add it to my queue
to merge to 10 in advance of 10.4.

-- 
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 203349] [META] FreeBSD Foundation sponsored project dependencies for FreeBSD 11.1

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203349
Bug 203349 depends on bug 204686, which changed state.

Bug 204686 Summary: panic: critical_exit: td_critnest == 0 running pmcstat 
(possible older HW issue)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204686

   What|Removed |Added

 Status|Open|Closed
 Resolution|--- |Unable to Reproduce

-- 
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 220035] [ufs] sys/ufs/ufs/ufs_vnops.c: a sleep-under-mutex bug in acl_alloc

[bugzilla-noreply]

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

Mateusz Guzik  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|m...@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 220035] [ufs] sys/ufs/ufs/ufs_vnops.c: a sleep-under-mutex bug in acl_alloc

[bugzilla-noreply]

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

Mateusz Guzik  changed:

   What|Removed |Added

 CC||m...@freebsd.org
 Status|New |Closed
 Resolution|--- |Not A Bug

--- Comment #1 from Mateusz Guzik  ---
Hi there, thanks for the report. This one is definitely a false-positive. The
code locks in the interlock to call vdropl, which returns with it unlocked. If
vdropl was not dropping the lock, the code would already be buggy due to
leaking the lock.

-- 
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 220037] [vfs] sys/kern/vfs_bio.c: a sleep-under-rwlock bug in getblk

[bugzilla-noreply]

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

Bug ID: 220037
   Summary: [vfs] sys/kern/vfs_bio.c: a sleep-under-rwlock bug in
getblk
   Product: Base System
   Version: 11.0-RELEASE
  Hardware: i386
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: baijiaju1...@163.com

The kernel may sleep under a rwlock, and the function call path in file
"sys/kern/vfs_bio.c" in FreeBSD 11.0 is:
getblk [line 3498: acquire the rwlock by BO_RLOCK]
  bp_unmapped_get_kva [line 3582]
bufspace_wait [line 3430]
  buf_flush [line 637] (rw_wunlock() is called, but not BO_RUNLOCK)
flushbufqueues [line 2977]
  malloc(M_WAITOK) [line 3093] --> may sleep

The possible fix of this bug is to set the last parameter "M_WAITOK" in malloc
to "M_NOWAIT".

This bug is found by a static analysis tool written by myself, and it is
checked by my review of the FreeBSD code.

By the way, I am a freshman in developing FreeBSD drivers, and I am willing to
submit a patch. But I do not know how to write and submit a patch, and where to
submit, so I am looking forward to useful advice :)

Jia-Ju Bai

-- 
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 220035] [ufs] sys/ufs/ufs/ufs_vnops.c: a sleep-under-mutex bug in acl_alloc

[bugzilla-noreply]

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

Jia-Ju Bai  changed:

   What|Removed |Added

   Hardware|Any |i386

-- 
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 220035] [ufs] sys/ufs/ufs/ufs_vnops.c: a sleep-under-mutex bug in acl_alloc

[bugzilla-noreply]

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

Bug ID: 220035
   Summary: [ufs] sys/ufs/ufs/ufs_vnops.c: a sleep-under-mutex bug
in acl_alloc
   Product: Base System
   Version: 11.0-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: baijiaju1...@163.com

The ufs program may sleep under a mutex, and the code path in file
"sys/ufs/ufs/ufs_vnops.c" in FreeBSD 11.0 is:
ufs_accessx [line 363: acquire the mutex]
ufs_accessx [line 369]
ufs_accessx [line 372]
ufs_accessx [line 374]
ufs_accessx [line 376]
ufs_accessx [line 379]
ufs_accessx [line 383]
ufs_accessx [line 389]
ufs_accessx [line 394]
ufs_accessx [line 395]
ufs_accessx [line 398]
  acl_alloc(M_WAITOK) [line 400] --> may sleep

The possible fix of these bugs is to set the parameter in acl_alloc to
"M_NOWAIT".

This bug is found by a static analysis tool written by myself, and it is
checked by my review of the FreeBSD code.

By the way, I am a freshman in developing FreeBSD drivers, and I am willing to
submit a patch. But I do not know how to write and submit a patch, and where to
submit, so I am looking forward to useful advice :)

Jia-Ju Bai

-- 
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 219405] NanoBSD NANO_PACKAGE_LIST does not support "*" anymore?

[bugzilla-noreply]

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

--- Comment #3 from w...@canodus.be ---
(In reply to karl from comment #2)

I am also using a PC Engines board. It is running smooth for almost a month
with the above patch.

Would be nice if this could be fixed in next release.

-- 
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 220033] [if_ixgb] sys/dev/ixgb/if_ixgb.c: a sleep-under-mutex bug in ixge_get_buf

[bugzilla-noreply]

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

Bug ID: 220033
   Summary: [if_ixgb] sys/dev/ixgb/if_ixgb.c: a sleep-under-mutex
bug in ixge_get_buf
   Product: Base System
   Version: 11.0-RELEASE
  Hardware: i386
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: baijiaju1...@163.com

The ixgb driver may sleep under a mutex, and the function call path in file
"sys/dev/ixgb/if_ixgb.c" in FreeBSD 11.0 is:
ixgb_init [line 750: acquire the mutex]
  ixgb_init_locked [line 751]
ixgb_setup_receive_structures [line 699]
  ixgb_allocate_receive_structures [line 1913]
ixgb_get_buf [line 1885]
  bus_dmamap_load(BUS_DMA_WAITOK) [line 1812] --> may sleep

The possible fix of these bugs is to set the last parameter in bus_dmamap_load
to "BUS_DMA_NOWAIT".

This bug is found by a static analysis tool written by myself, and it is
checked by my review of the FreeBSD code.

By the way, I am a freshman in developing FreeBSD drivers, and I am willing to
submit a patch. But I do not know how to write and submit a patch, and where to
submit, so I am looking forward to useful advice :)

Jia-Ju Bai

-- 
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 220032] [if_alc] sys/dev/alc/if_alc.c: sleep-under-mutex bugs

[bugzilla-noreply]

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

Bug ID: 220032
   Summary: [if_alc] sys/dev/alc/if_alc.c: sleep-under-mutex bugs
   Product: Base System
   Version: 11.0-RELEASE
  Hardware: i386
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: baijiaju1...@163.com

The alc driver may sleep under a mutex, and the function call paths in file
"sys/dev/alc/if_alc.c" in FreeBSD 11.0 is:
alc_resume [line 2648: acquire the mutex]
  alc_init_locked [line 2664]
alc_init_rx_ring [line 3911]
  alc_newbuf [line 4469]
bus_dmamap_load_mbuf_sg(BUS_DMA_WAITOK) [line 3472] --> may sleep

alc_int_task [line 3330: acquire the mutex]
  alc_start_locked [line 3372]
alc_encap [line 2942]
  bus_dmamap_load_mbuf_sg(BUS_DMA_WAITOK) [line 2780] --> may sleep

The possible fix of these bugs is to set the last parameter in
bus_dmamap_load_mbuf_sg to "BUS_DMA_NOWAIT".

This bug is found by a static analysis tool written by myself, and it is
checked by my review of the FreeBSD code.

By the way, I am a freshman in developing FreeBSD drivers, and I am willing to
submit a patch. But I do not know how to write and submit a patch, and where to
submit, so I am looking forward to useful advice :)

Jia-Ju Bai

-- 
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 220024] head -r319991 clang powerpc64 and powerpc toolchains (cross build target): boot1.o: In function `fsread_size': undefined reference to `__udivdi3'

[bugzilla-noreply]

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

--- Comment #3 from Mark Millard  ---
(In reply to Mark Millard from comment #2)

The prior powerpc64 example was using the system
binutils, just like I had done for powerpc (32-bit).

The problem still occurs when the likes of:

-B/usr/local/powerpc64-freebsd/bin/

is in use instead:

--- boot1.elf ---
boot1.o: In function `fsread_size':
/usr/src/sys/boot/powerpc/boot1.chrp/boot1.c:(.text+0x14b8): undefined
reference to `__udivdi3'
/usr/src/sys/boot/powerpc/boot1.chrp/boot1.c:(.text+0x1508): undefined
reference to `__udivdi3'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
--- all_subdir_tests ---
Building
/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tests/sys/mqueue/mqtest2.full
--- all_subdir_sys ---
*** [boot1.elf] Error code 1

make[6]: stopped in /usr/src/sys/boot/powerpc/boot1.chrp
.ERROR_TARGET='boot1.elf'
.ERROR_META_FILE='/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/sys/boot/powerpc/boot1.chrp/boot1.elf.meta'


# more
/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/sys/boot/powerpc/boot1.chrp/boot1.elf.meta
# Meta data file
/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/sys/boot/powerpc/boot1.chrp/boot1.elf.meta
CMD cc -target powerpc64-unknown-freebsd12.0
--sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp
-B/usr/local/powerpc64-freebsd/bin/ -ffreestanding -msoft-float
-I/usr/src/sys/boot/powerpc/boot1.chrp/../../common
-I/usr/src/sys/boot/powerpc/boot1.chrp/../../../ -D_STANDALONE -m32
-mcpu=powerpc -m32 -mcpu=powerpc -std=gnu99 -Qunused-arguments -nostdlib
-static -Wl,-N -Wl,-m -Wl,elf32ppc_fbsd -Wl,-m -Wl,elf32ppc_fbsd -o boot1.elf
boot1.o ashldi3.o syncicache.o  
CWD
/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/sys/boot/powerpc/boot1.chrp
TARGET boot1.elf
-- command output --
boot1.o: In function `fsread_size':
/usr/src/sys/boot/powerpc/boot1.chrp/boot1.c:(.text+0x14b8): undefined
reference to `__udivdi3'
/usr/src/sys/boot/powerpc/boot1.chrp/boot1.c:(.text+0x1508): undefined
reference to `__udivdi3'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1


# more
~/sys_build_scripts.amd64-host/make_powerpc64vtsc_nodebug_clang_altbinutils-amd64-host.sh
 
kldload -n filemon && \
script
~/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinutils-amd64-host-$(date
+%Y-%m-%d:%H:%M:%S) \
env __MAKE_CONF="/root/src.configs/make.conf" SRCCONF="/dev/null"
SRC_ENV_CONF="/root/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-host"
\
WITH_META_MODE=yes \
MAKEOBJDIRPREFIX="/usr/obj/powerpc64vtsc_clang_altbinutils" \
make $*


# more
/root/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-host
TO_TYPE=powerpc64
TOOLS_TO_TYPE=${TO_TYPE}
VERSION_CONTEXT=12.0
#
KERNCONF=GENERIC64vtsc-NODBG
TARGET=powerpc
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITH_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=
#
WITH_LIBCPLUSPLUS=
WITHOUT_BINUTILS_BOOTSTRAP=
WITH_ELFTOOLCHAIN_BOOTSTRAP=
WITH_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITHOUT_LLD_BOOTSTRAP=
WITH_LLD=
WITHOUT_LLD_IS_LD=
WITH_LLDB=
#
WITH_BOOT=
WITH_LIB32=
#
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
MALLOC_PRODUCTION=
#
# Avoid converts between pointers to integer types with different sign
[-Werror,-Wpointer-sign]
# and such from blocking the build.
WERROR=
#
WITH_REPRODUCIBLE_BUILD=
WITH_DEBUG_FILES=
#
#
# For TO (so-called "cross") stages . . .
# So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . .
# TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . .
#
CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/
.if ${.MAKE.LEVEL} == 0
#
# Note: The WITH_CROSS_COMPILER picks up the CROSS_BINUTILS_PREFIX
#   binding automatically.
#
XAS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as
XAR=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar
XNM=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm
XOBJCOPY=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy
XOBJDUMP=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump
XRANLIB=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib
XSIZE=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size
#NO-SUCH: XSTRINGS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings
XSTRINGS=/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings
.export XAS
.export XAR
.export XNM
.export XOBJCOPY
.export XOBJDUMP
.export XRANLIB
.export XSIZE
.export XSTRINGS
XLD=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld
.export XLD
.endif

-- 
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 220024] head -r319991 clang powerpc64 and powerpc toolchains (cross build target): boot1.o: In function `fsread_size': undefined reference to `__udivdi3'

[bugzilla-noreply]

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

Mark Millard  changed:

   What|Removed |Added

Summary|head -r319991 clang powerpc |head -r319991 clang
   |toolchain (cross build  |powerpc64 and powerpc
   |target): boot1.o: In|toolchains (cross build
   |function `fsread_size': |target): boot1.o: In
   |undefined reference to  |function `fsread_size':
   |`__udivdi3' |undefined reference to
   ||`__udivdi3'

--- Comment #2 from Mark Millard  ---
(In reply to Mark Millard from comment #1)

powerpc64 has the same buildworld problem:

--- boot1.elf ---
boot1.o: In function `fsread_size':
/usr/src/sys/boot/powerpc/boot1.chrp/boot1.c:(.text+0x14b8): undefined
reference to `__udivdi3'
/usr/src/sys/boot/powerpc/boot1.chrp/boot1.c:(.text+0x1508): undefined
reference to `__udivdi3'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
--- all_subdir_usr.sbin ---
Building
/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/usr.sbin/fstyp/ext2fs.o
--- all_subdir_sys ---
*** [boot1.elf] Error code 1

make[6]: stopped in /usr/src/sys/boot/powerpc/boot1.chrp
.ERROR_TARGET='boot1.elf'
.ERROR_META_FILE='/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/sys/boot/powerpc/boot1.chrp/boot1.elf.meta'

-- 
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 220028] ports-mgmt/pkg: "pkg remove -a" doesn't remove package after "pk" in alphabetic order

[bugzilla-noreply]

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

dasti  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|New |Closed

--- Comment #1 from dasti  ---


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

-- 
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 220024] head -r319991 clang powerpc toolchain (cross build target): boot1.o: In function `fsread_size': undefined reference to `__udivdi3'

[bugzilla-noreply]

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

--- Comment #1 from Mark Millard  ---
(In reply to Mark Millard from comment #0)

boot1.o: In function `fsread_size':
/usr/src/sys/boot/powerpc/boot1.chrp/boot1.c:(.text+0x14b8): undefined
reference to `__udivdi3'
/usr/src/sys/boot/powerpc/boot1.chrp/boot1.c:(.text+0x1508): undefined
reference to `__udivdi3'
cc: error: linker command failed with exit code 1 (use -v to see invocation)

is from the buildworld part of the overall build
attempt.

I'll note that back in -r317820 and before I was
able to buildworld and installworld based on the
system clang and use the installed world on an
old PowerMac (other than handling thrown C++
exceptions).


Also: trying buildkernel separately after the
buildworld failure worked fine. [That does not
mean that such a clang-based kernel would
complete the boot sequence on an old PowerMac.]

-- 
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 220028] ports-mgmt/pkg: "pkg remove -a" doesn't remove package after "pk" in alphabetic order

[bugzilla-noreply]

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

Bug ID: 220028
   Summary: ports-mgmt/pkg: "pkg remove -a" doesn't remove package
after "pk" in alphabetic order
   Product: Base System
   Version: 11.0-STABLE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: bin
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: stievenard.da...@gmail.com

pkg 1.10.1
FreeBSD 11.0-RELEASE-p1 


---
the doc says
---
pkg remove

 -a, --all  Deletes all installed packages except for pkg(8) from the
system and cleans the database of information related to
removed packages.

---
when I try
---
root@test-server-1:~ # pkg remove -a
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 7 packages (of 0 packages
in the universe):

Installed packages to be REMOVED:
pkg-1.10.1
png-1.6.29
renderproto-0.11.1
scrnsaverproto-1.2.2
tcl86-8.6.6_2
xextproto-7.3.0
xproto-7.0.31

Number of packages to be removed: 7

The operation will free 20 MiB.

Proceed with deinstalling packages? [y/N]: y
pkg: Cannot delete pkg itself without force flag

---
my understanding
---
it seems that pkg goes into the list of packages in alphabetic order to delete.
When it reaches pkg itself, without the "-f" flag, it doesn't uninstall it and
stops there in stead of carrying on in the list.


best regards
dasti

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