[Bug 245541] [panic ] fault code = supervisor read data, page not present
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245541 Sebastian S changed: What|Removed |Added Status|New |Closed Resolution|--- |FIXED --- Comment #3 from Sebastian S --- Swapping the memory solved the issue. -- 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 251372] fetch(1) silently accepts invalid options
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251372 Bug ID: 251372 Summary: fetch(1) silently accepts invalid options Product: Base System Version: 12.2-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: ltning-free...@anduin.net The fetch(1) command silently accepts certain invalid options given on the command line. E.g. fetch -no-verify-hostname -o - https://freebsd.org/ is expected to return an error, given the mistyped (-)-no-verify-hostname option. Silently ignoring invalid/unknown options is potentially dangerous. -- 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 251372] fetch(1) silently accepts invalid options
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251372 Eirik Oeverby changed: What|Removed |Added Resolution|--- |Not A Bug Severity|Affects Some People |Affects Only Me Status|New |Closed --- Comment #1 from Eirik Oeverby --- Turns out -n is a valid option, -o takes an argument, so this gave an output file called '-verify-hostname'. Apologies. -- 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 251376] Regression in lid switch behavior on Toshiba Satellite
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251376 Bug ID: 251376 Summary: Regression in lid switch behavior on Toshiba Satellite Product: Base System Version: 12.2-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: j...@freebsd.org Since upgrading to 12.2-RELEASE, the lid switch does not trigger S3 mode on my Toshiba Satellite, only after a fresh boot. Instead, the machine keeps running while closed. Manually putting it to sleep via the Lumina exit menu works, and the lid switch then works fine on subsequent closes until the next reboot. This is a regression from 12.1-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 251376] Regression in lid switch behavior on Toshiba Satellite
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251376 Mark Linimon changed: What|Removed |Added Keywords||regression -- 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 251274] panic: recursive fpu_kern_enter while in PCB_FPUNOSAVE state
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251274 --- Comment #2 from Juraj Lutter --- With today's CURRENT and openzfs (sysutils/openzfs-kmod) I'm getting: nda21: 1526185MB (3125627568 512 byte sectors) Fatal trap 12: page fault while in kernel mode cpuid = 27; apic id = 1b fault virtual address = 0x58 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80bc1f09 stack pointer = 0x28:0xfe01a3f59b80 frame pointer = 0x28:0xfe01a3f59bc0 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) trap number = 12 panic: page fault cpuid = 27 time = 115 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe01a3f59830 vpanic() at vpanic+0x181/frame 0xfe01a3f59880 panic() at panic+0x43/frame 0xfe01a3f598e0 trap_fatal() at trap_fatal+0x387/frame 0xfe01a3f59940 trap_pfault() at trap_pfault+0x97/frame 0xfe01a3f599a0 trap() at trap+0x2ab/frame 0xfe01a3f59ab0 calltrap() at calltrap+0x8/frame 0xfe01a3f59ab0 --- trap 0xc, rip = 0x80bc1f09, rsp = 0xfe01a3f59b80, rbp = 0xfe01a3f59bc0 --- __mtx_lock_flags() at __mtx_lock_flags+0x49/frame 0xfe01a3f59bc0 zone_dataset_visible() at zone_dataset_visible+0x6b/frame 0xfe01a3f59c10 zfs_mount() at zfs_mount+0x26c/frame 0xfe01a3f59d90 vfs_domount() at vfs_domount+0x89c/frame 0xfe01a3f5a000 vfs_donmount() at vfs_donmount+0x872/frame 0xfe01a3f5a0a0 kernel_mount() at kernel_mount+0x57/frame 0xfe01a3f5a0f0 parse_mount() at parse_mount+0x4a1/frame 0xfe01a3f5a230 vfs_mountroot() at vfs_mountroot+0x589/frame 0xfe01a3f5a3a0 start_init() at start_init+0x1f/frame 0xfe01a3f5a430 fork_exit() at fork_exit+0x80/frame 0xfe01a3f5a470 fork_trampoline() at fork_trampoline+0xe/frame 0xfe01a3f5a470 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter: panic [ thread pid 1 tid 12 ] Stopped at kdb_enter+0x37: movq$0,0x10ac246(%rip) -- 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 251274] panic: recursive fpu_kern_enter while in PCB_FPUNOSAVE state
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251274 --- Comment #3 from Juraj Lutter --- And this is happening on 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 251363] use unionfs as a disk-cache for NFS [feature]
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251363 --- Comment #5 from Gunther Schadow --- Updated the stackexchange link with a draft design to allow to use rm and rmdir to evict entries from the cache, new whitemode UNIONFS_WHITE_NEVER would do that. I love how the kernel sources seem to be quite clean and it is easy to add these improvements. At least that's my impression before actually having run any of them (kernel is still compiling on a AWS EC2 t2.micro instance with no remaining CPU credits -- reminds me of compiling the 386BSD kernel in 1992 on my i486 PC (or the Ultix 4.2 kernel on the VAX 6000-340 ;-) ) -- 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"
Was wäre, wenn Wohlstand Garantiert wäre und ohne Risiko?
Endlich automatisiertes System, das echten Wohlstand schafft Hier geht es zur Onlineversion Hier klicken Ausgabe 783 vom 25.11.20 Was wäre, wenn Wohlstand Garantiert wäre und ohne Risiko? Vermögens Bildungssystem Endlich automatisiertes System, das echten Wohlstand schafft Lass mich Ihnen ein paar Fragen stellen? 1 - Was wäre, wenn es eine GLOBAL COMPANY gäbe, die Garantiert ein Home Based Business für Sie Aufbaut? 2 - Ran Targeted Traffic (KUNDEN) und Verkaufte Digitale Produkte auf dem neuesten Stand der Technik für Sie? 3 - Hat gesamte KUNDEN SERVICE FÜR SIE? 4 - Alles, was Sie tun müssen, ist, täglich Wöchentlich, Monatlich Geld zu sammeln? ** VOLLSTÄNDIG AUTOMATISIERTES HAND FREIES SYSTEM !! Hallo liebe/er Geschäftsfreund/in Mein name ist Toni Zeyko V. Ich bin seit 2018 ein Early Bird Founder von Onpassive LLC. Was Onpassive ist könnte ich Ihnen ein Text schreiben der sehr lange werden könnte. Wir haben uns Entschlossen zwei Video^s die kurz und Effektiv wirken. Es ist einmal auf Deutsche und Englische Sprache verfügbar. ( Bitte schauen Sie sich beide Videos an!) Deutschesprachige Präsentation: https://trimurl.co/DeutschsprachigePraesentation Englishe Presentation https://trimurl.co/EnglishPresentations Hier noch paar Punkte bezogen auf Onpassive: LLC - Onpassive ist Registriert bei BBB - Über 212 Länder Registriert und Lizenziert - Hauptsitz in Orlando/Florida, zwei weitere Büros in Bangalore und Hyderbad (Indien) - Bis ende 2020 1000 Mitarbeiter (Onpassive ist noch in Prelaunch) - OnPassive hat derzeit einen Wert von 3 Milliarden US -Dollar aufgrund der Produkte - 100% Risikolos.. - Wenn Onpassive Startet wird es nie wieder eine Founder position Angeboten - Onpassive hat sein eigenes persönliches Kommunikations Chat für Founder - Wöchentliche Webinare mit Führungskräfte und CEO(Founder Mr. Ash Mufareh) werden veranstaltet - Öffentliche Webinar veranstaltungen von Onpassive jede Woche, mehrmals auf Englische Sprache - OnPassive wird von Generation zu vererbbar sein - OnPassive wird nach zweites Geschäftsjahres eine Unicorn Company werden - Uvm Wenn Sie Founder werden,werde ich Sie und mein Team unterstützen: 1. Wir haben ein Telegramm Chat nur für Founder 2. Falls Sie ein Team aufbauen möchten (nicht pflicht bei Onpassive),wir unterstützen Sie durch Zoom Call,Sie müssen nur ihre Interessenten einladen zum Zoom Call . Später müssen Sie Ihren Interessenten bei registrieren helfen. Ist das ein DEAL für Sie ? 3. Uvm Werden Sie jetzt ein Early Bird Founder für 97$. Sehr bald wird Founder Spot auf 149$ erhöht und das auch nur für kurze Zeit Zum Registrieren: https://trimurl.co/Zukunftorentiert Zur direct registration: https://trimurl.co/WfGeJYr Die 97$ können mit BTC,Kredit Karte und mit Debit Karte bezahlen. Wir würden uns sehr freuen Sie in Founder Kommunikation Chat, Sie zu begrüßen persönlich. Warten Sie nicht lange,Onpassive startet noch dieses Jahr. Es lohnt sich für beide seiten!! Für Selbständige,Networker, Firmen usw UND auch für die kein Business betreiben, dan wird ganz einfach Onpassive das Business heissen. Mit besten Grüßen, Toni Zeyko V. - Early Bird Founder seit 2018 (Admin von TeamElite - Onpassive) Kontakt: Email: onpassivet...@email.de (Betreff: Founder) Cortisol – Warum blockiert ein zu hoher Cortisolspiegel das Abnehmen? Cortisol – Warum blockiert ein zu hoher Cortisolspiegel das Abnehmen? Was sind die Zeichen für eine zu hohe Cortisolausschüttung im Körper? Welchen Einfluss hat die Trainingsintensität und Dauer auf den Cortisolspiegel und was kann man bei erhöhtem Cortisolspiegel tun um ihn zu senken? Die "Cortisol Lösung" FGF2 ist die scheinbar geniale Lösung zur Senkung des Cortisol-Spiegels und die gleichzeitige Erhöhung des Serotonin-Spiegels sowie der Spiegel folgender Neurotransmitter: Dopamin, Acetylcholin und GABA. Das führt zu – gehobener Stimmung – weniger Ängsten und mehr Mut – weniger Heißhunger – schnellere Denkprozesse und geistige Klarheit. Dem gegenüber führt ein zu hoher Cortisol-Spiegel zu – verfrühten Alterungsprozessen – Entstehung chronischer Krankheiten (z.B. Diabetes Typ 2) – Übergewicht – Verhinderung der Produktion körpereigener Hormone, was man u.a. in den Wechseljahren merkt.“ MLM Verteiler-24 & MLM-Anzeiger-24 Der Newsletter für die Network Marketing Branche | mlm-verteiler24.de | Email MLM-Verteiler24- Lake Forest 92630 - USA Unsere registrierten User erhalten 1-2 mal monatlich den www.MLM-Verteiler24.de Du möchtest dich vom Newsletter abmelden? Dann klickst du bitte Unsubscribe. ©2020 MLM Verteiler 24. All rights reserved. ___ 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 251347] NFS hangs on client side when mounted from outside in Jail Tree (BROKEN NFS SERVER OR MIDDLEWARE)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251347 Konstantin Belousov changed: What|Removed |Added CC||k...@freebsd.org --- Comment #5 from Konstantin Belousov --- First, switch to 12.2. There were fixes for some NFS client issues that might be relevant (could be not). I am sure that NFS client is not VNET-aware, i.e. it does not switch context to the proper VNET as needed. Esp. when offloading async io to nfsiod daemons. In other words, I do not expect the scenario 3 to work. For the second scenario, nullfs remount of NFS mount, VNET jail should be irrelevant. When the hang occurs, gather the procstat -kk -a output (on the host). Also it might worth a try to '-o nocache' for nullfs mounts, I remember there were some problems with nullfs+nfs+caching. -- 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 251347] NFS hangs on client side when mounted from outside in Jail Tree (BROKEN NFS SERVER OR MIDDLEWARE)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251347 Rick Macklem changed: What|Removed |Added CC||rmack...@freebsd.org --- Comment #6 from Rick Macklem --- I am not a jails guy, so I don't know if that was a factor. W.r.t "..BROKEN MIDDLEWARE.." It refers to a case where something between the NFS server and client tries to cache Getattr replies, but doesn't get it right. Try testing where the NFS client connects to the server without anything like a cisco switch in between. Just a wire or a really dumb no frills switch. Also, try an NFSv4 mount, since the NFSv4 RPCs are much harder to cache and send replies. If the problem persists, add another comment to this bug report and we can try some other stuff. (The error is generated because a file's fileno has changed and that should never happen.) My guess is that having the two mounts for the same file system has somehow triggered the generation of a bogus cached reply. -- 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 251347] NFS hangs on client side when mounted from outside in Jail Tree (BROKEN NFS SERVER OR MIDDLEWARE)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251347 --- Comment #7 from Arne Steinkamm --- (In reply to Rick Macklem from comment #6) Thanks Rick, as said before: Using NFSv4 changes nothing :-( I'm unable to change the wiring because the complete setup is in a computer center 600km from here but I have access to all lights out service processors, the switches, etc. I have the same problem now with a Linux NFS server so I think the problem is not on the server side. To make the picture clearer: two main administrative servers: adm001 and adm002 Both have a couple of VNET jails (if_bridge, not netgraph) running nameserver etc. And both have so called login server jails. Just a jail where the people can ssh too and jump (ssh) inside the development networks. Two fileserver, one Linux one FreeBSD share the $HOMEs and a pool share. These are mounted at adm001 and amd002 to /l/home and /l/pool. NULLFS mounts forward these in the two login jails: /l/home --> /l/prison/login1/l/home and /l/pool --> /l/prison/login1/l/pool. Same procedure on adm002 with login002. After 30 seconds to 60 minutes one of the two NFS mounts freezes. df, ls, umount etc. hang. And now the strange part: "sh /etc/rc.d/jail stop login1" immediately unfreezes the NFS mount and everything is working normal again but, of course, without the jail. In the second the Jail is dead the "BROKEN NFS..." text is displayed only on the console, not in dmesg buffer or log files and, this is strange, only on adm001. adm001 and adm002 are different hardware (other CPU) but there are clones, real clones made with zfs send/receive. Of course the hostids are different. The workaround is to allow the users to use adm001 and adm002 directly. But this is not the way we want to have it. When I don't use the NULLFS and make two independent NFS mounts to /l/home and /l/prison/login1/l/home then only the second freezes. I guess this is not normal and a real bug... Any help? Thanks in advance .//. Arne -- 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 251363] use unionfs as a disk-cache for NFS [feature]
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251363
--- Comment #6 from Gunther Schadow ---
Success! Here is my full diff in /usr/src/sys/fs/unionfs
# svnlite diff -x-w
Index: union.h
===
--- union.h (revision 368012)
+++ union.h (working copy)
@@ -40,6 +40,12 @@
#ifdef _KERNEL
+/* copy policy from lower to upper layer */
+typedef enum _unionfs_copypolicy {
+UNIONFS_COPY_ON_WRITE = 0,
+UNIONFS_COPY_ALWAYS
+} unionfs_copypolicy;
+
/* copy method of attr from lower to upper */
typedef enum _unionfs_copymode {
UNIONFS_TRADITIONAL = 0,
@@ -57,6 +63,7 @@
struct vnode *um_lowervp; /* VREFed once */
struct vnode *um_uppervp; /* VREFed once */
struct vnode *um_rootvp; /* ROOT vnode */
+unionfs_copypolicy um_copypolicy;
unionfs_copymode um_copymode;
unionfs_whitemode um_whitemode;
uid_t um_uid;
Index: union_vfsops.c
===
--- union_vfsops.c (revision 368012)
+++ union_vfsops.c (working copy)
@@ -89,6 +89,7 @@
gid_t gid;
u_short udir;
u_short ufile;
+ unionfs_copypolicy copypolicy;
unionfs_copymode copymode;
unionfs_whitemode whitemode;
struct nameidata nd, *ndp;
@@ -102,6 +103,7 @@
gid = 0;
udir = 0;
ufile = 0;
+ copypolicy = UNIONFS_COPY_ON_WRITE;
copymode = UNIONFS_TRANSPARENT; /* default */
whitemode = UNIONFS_WHITE_ALWAYS;
ndp = &nd;
@@ -190,6 +192,20 @@
return (EINVAL);
}
}
+ if (vfs_getopt(mp->mnt_optnew, "copypolicy", (void **)&tmp,
+ NULL) == 0) {
+ if (tmp == NULL) {
+ vfs_mount_error(mp, "Invalid copy policy");
+ return (EINVAL);
+ } else if (strcasecmp(tmp, "always") == 0)
+ copypolicy = UNIONFS_COPY_ALWAYS;
+ else if (strcasecmp(tmp, "onwrite") == 0)
+ copypolicy = UNIONFS_COPY_ON_WRITE;
+ else {
+ vfs_mount_error(mp, "Invalid copy policy");
+ return (EINVAL);
+ }
+ }
if (vfs_getopt(mp->mnt_optnew, "copymode", (void **)&tmp,
NULL) == 0) {
if (tmp == NULL) {
@@ -229,7 +245,7 @@
UNIONFSDEBUG("unionfs_mount: uid=%d, gid=%d\n", uid, gid);
UNIONFSDEBUG("unionfs_mount: udir=0%03o, ufile=0%03o\n", udir, ufile);
- UNIONFSDEBUG("unionfs_mount: copymode=%d\n", copymode);
+UNIONFSDEBUG("unionfs_mount: copypolicy=%d, copymode=%d,
whitemode=%d\n", copypolicy, copymode, whitemode);
/*
* Find upper node
@@ -265,6 +281,7 @@
ump->um_gid = gid;
ump->um_udir = udir;
ump->um_ufile = ufile;
+ ump->um_copypolicy = copypolicy;
ump->um_copymode = copymode;
ump->um_whitemode = whitemode;
Index: union_vnops.c
===
--- union_vnops.c (revision 368012)
+++ union_vnops.c (working copy)
@@ -464,6 +464,7 @@
{
int error;
struct unionfs_node *unp;
+ struct unionfs_mount *ump;
struct unionfs_node_status *unsp;
struct vnode *uvp;
struct vnode *lvp;
@@ -477,6 +478,7 @@
error = 0;
unp = VTOUNIONFS(ap->a_vp);
+ ump = MOUNTTOUNIONFSMOUNT(ap->a_vp->v_mount);
uvp = unp->un_uppervp;
lvp = unp->un_lowervp;
targetvp = NULLVP;
@@ -498,7 +500,7 @@
}
if (targetvp == NULLVP) {
if (uvp == NULLVP) {
- if ((ap->a_mode & FWRITE) && lvp->v_type == VREG) {
+ if (((ap->a_mode & FWRITE) || (ump->um_copypolicy ==
UNIONFS_COPY_ALWAYS)) && lvp->v_type == VREG) {
error = unionfs_copyfile(unp,
!(ap->a_mode & O_TRUNC), cred, td);
if (error != 0)
r
Testing:
# mdconfig -a -t vnode /data/cachfs
md0
newfs /dev/md0
/dev/md0: 1024.0MB (2097152 sectors) block size 32768, fragment size 4096
using 4 cylinder groups of 256.03MB, 8193 blks, 32896 inodes.
super-block backups (for fsck_ffs -b #) at:
192, 524544, 1048896, 1573248
# mkdir /cache
# mount /dev/md0 /cache
# mount_unionfs -o copypolicy=always /cache /worker-efs
# /efs/bin/less
...
# /efs/local/bin/python3.7
...
# find /cache
cache
cache/.snap
cache/bin
cache/bin/less
cache/sbin
cache/local
cache/local/bin
cache/local/bin/python3.7
cache/local/lib
cache/local/lib/python3.7
cache/local/lib/python3.7/lib-dynload
cache/local/lib/python3.7/lib-dynload/readline.so
cache/local/lib/python3.7/encodings
ca
[Bug 251363] use unionfs as a disk-cache for NFS [feature]
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251363 --- Comment #7 from Gunther Schadow --- Erratum: I said "I can evict from the cache by writing to the unionfs" -- I meant by removing files from that /cache file system. I wasn't clear that in order to mount a unionfs, you must already have the upper layer file system mounted somewhere. And then you can access just the upper layer, where we can clear the cache. So I do not need that UNIONFS_WHITE_NEVER option at all. What might be cool was some kind of hook to register if the unionfs_copyfile errors with no space left on device, we could call that evictor hook, which then would delete from the upper layer by oldest atime. -- 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 251389] linuxkpi malloc is not strictly compatible with Linux
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251389 Bug ID: 251389 Summary: linuxkpi malloc is not strictly compatible with Linux Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: jhibb...@freebsd.org Linux's kmalloc seems to provide the following guarantees: * GPF_KERNEL returns memory in the lower 4GB physical space * Allocations are physically contiguous malloc(9) does not make either of these guarantees. This ends up breaking DRM modules on powerpc64 platforms, where even if memory happens to be contiguous it may not be in the bottom 4GB physical address space, and it may even be in a different NUMA domain, where NUMA domains are physically indexed at 1<<45, such that the bottom 4GB of the second NUMA domain doesn't fit into the 40-bit PA range accessible to Radeon GPUs. Contiguity can be emulated with contigmalloc(9), but that's not a viable solution for replacing all calls, as it's very possible for the size to not be known and traceable through the lifetime of a pointer. -- 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 250580] VMware UEFI guests crash in virtual hardware after r366691
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250580 --- Comment #17 from Hongbo He --- (In reply to Christian Ullrich from comment #13) > 6. Delete the VM's .nvram file. That's interesting! Besides the trick that entering the EFI shell before boot, I've tried removing the VM's .nvram file in ESXi's datastore file browser, which will also result in a successful boot, but only once. After a reboot (inc. cold boot and hot reboot) it will fail again and needs another purge of its NVRAM file, or entering the EFI shell as I mentioned in comment #5. -- 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 250580] VMware UEFI guests crash in virtual hardware after r366691
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250580 --- Comment #18 from Hongbo He --- In addition to comment #17, I've just tried purging NVRAM with 12.2 RC3 (Which TrueNAS 12.0 shipped as it's kernel) with no luck. 12.2-RELEASE will boot as normal while 12.2 RC3 will result in a reboot(not a shutdown of the VM), and then a firmware crash that leads to the VM being shutdown. "Entering the EFI Shell" trick works for both, however. -- 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 251363] use unionfs as a disk-cache for NFS [feature]
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251363 --- Comment #8 from Gunther Schadow --- Another erratum, I didn't realize at first the unionfs doesn't even require a block device nor a mount-point directory, but rather, it can use any directory. This is awesome, so none of this mdconfig and newfs suff is needed at all. Forget that part of my test. -- 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 251363] use unionfs as a disk-cache for NFS [feature]
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251363
--- Comment #9 from Gunther Schadow ---
For completeness sake, I updated the mount_unionfs.8 man file also.
Full diff out of /usr/src with svnlite diff -x-w:
Index: sbin/mount_unionfs/mount_unionfs.8
===
--- sbin/mount_unionfs/mount_unionfs.8 (revision 368012)
+++ sbin/mount_unionfs/mount_unionfs.8 (working copy)
@@ -83,6 +83,16 @@
However,
.Ar uniondir
remains the mount point.
+.It Cm copypolicy No = Cm onwrite | always
+The normal behavior is copy-on-write with
+.Cm onwrite
+this is the standaed unionfs behavior. If
+.Cm always
+is spefied, then the a copy is made on the upper layer even if the
+file or directory is accessed only for reading. This effectively
+turns the upper layer into a cache which is an easy way to implement
+a disk cache over an NFS filesystem, speeding up all subsequent accesses,
+very useful for network booted systems.
.It Cm copymode No = Cm traditional | transparent | masquerade
Specifies the way to create a file or a directory in the upper layer
automatically when needed.
Index: sys/fs/unionfs/union.h
===
--- sys/fs/unionfs/union.h (revision 368012)
+++ sys/fs/unionfs/union.h (working copy)
@@ -40,6 +40,12 @@
#ifdef _KERNEL
+/* copy policy from lower to upper layer */
+typedef enum _unionfs_copypolicy {
+UNIONFS_COPY_ON_WRITE = 0,
+UNIONFS_COPY_ALWAYS
+} unionfs_copypolicy;
+
/* copy method of attr from lower to upper */
typedef enum _unionfs_copymode {
UNIONFS_TRADITIONAL = 0,
@@ -57,6 +63,7 @@
struct vnode *um_lowervp; /* VREFed once */
struct vnode *um_uppervp; /* VREFed once */
struct vnode *um_rootvp; /* ROOT vnode */
+unionfs_copypolicy um_copypolicy;
unionfs_copymode um_copymode;
unionfs_whitemode um_whitemode;
uid_t um_uid;
Index: sys/fs/unionfs/union_vfsops.c
===
--- sys/fs/unionfs/union_vfsops.c (revision 368012)
+++ sys/fs/unionfs/union_vfsops.c (working copy)
@@ -89,6 +89,7 @@
gid_t gid;
u_short udir;
u_short ufile;
+ unionfs_copypolicy copypolicy;
unionfs_copymode copymode;
unionfs_whitemode whitemode;
struct nameidata nd, *ndp;
@@ -102,6 +103,7 @@
gid = 0;
udir = 0;
ufile = 0;
+ copypolicy = UNIONFS_COPY_ON_WRITE;
copymode = UNIONFS_TRANSPARENT; /* default */
whitemode = UNIONFS_WHITE_ALWAYS;
ndp = &nd;
@@ -190,6 +192,20 @@
return (EINVAL);
}
}
+ if (vfs_getopt(mp->mnt_optnew, "copypolicy", (void **)&tmp,
+ NULL) == 0) {
+ if (tmp == NULL) {
+ vfs_mount_error(mp, "Invalid copy policy");
+ return (EINVAL);
+ } else if (strcasecmp(tmp, "always") == 0)
+ copypolicy = UNIONFS_COPY_ALWAYS;
+ else if (strcasecmp(tmp, "onwrite") == 0)
+ copypolicy = UNIONFS_COPY_ON_WRITE;
+ else {
+ vfs_mount_error(mp, "Invalid copy policy");
+ return (EINVAL);
+ }
+ }
if (vfs_getopt(mp->mnt_optnew, "copymode", (void **)&tmp,
NULL) == 0) {
if (tmp == NULL) {
@@ -229,7 +245,7 @@
UNIONFSDEBUG("unionfs_mount: uid=%d, gid=%d\n", uid, gid);
UNIONFSDEBUG("unionfs_mount: udir=0%03o, ufile=0%03o\n", udir, ufile);
- UNIONFSDEBUG("unionfs_mount: copymode=%d\n", copymode);
+UNIONFSDEBUG("unionfs_mount: copypolicy=%d, copymode=%d,
whitemode=%d\n", copypolicy, copymode, whitemode);
/*
* Find upper node
@@ -265,6 +281,7 @@
ump->um_gid = gid;
ump->um_udir = udir;
ump->um_ufile = ufile;
+ ump->um_copypolicy = copypolicy;
ump->um_copymode = copymode;
ump->um_whitemode = whitemode;
Index: sys/fs/unionfs/union_vnops.c
===
--- sys/fs/unionfs/union_vnops.c(revision 368012)
+++ sys/fs/unionfs/union_vnops.c(working copy)
@@ -464,6 +464,7 @@
{
int error;
struct unionfs_node *unp;
+ struct unionfs_mount *ump;
struct unionfs_node_status *unsp;
struct vnode *uvp;
struct vnode *lvp;
@@ -477,6 +478,7 @@
error = 0;
unp = VTOUNIONFS(ap->a_vp);
+ ump = MOUNTTOUNIONFSMOUNT(ap->a_vp->v_mount);
uvp = unp->un_uppervp;
lvp = unp->un_lowervp;
targetvp = NULLVP;
@@ -498,7 +500,7 @@
}
if (targetvp == NULLVP) {
if (uvp == NULL
[Bug 251363] use unionfs as a disk-cache for NFS [feature]
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251363 Gunther Schadow changed: What|Removed |Added Version|Unspecified |12.2-RELEASE Severity|Affects Only Me |Affects Some People --- Comment #10 from Gunther Schadow --- (forget the r in last line above) I read the Handbook about how contributions are submitted and I am glad to have found out that they are submitted on bug tickets. So that is what I did. I think you want to include this in some of the next releases. It's such a useful and inoffensive new feature! -- 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 251363] use unionfs as a disk-cache for NFS [feature]
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251363 --- Comment #11 from Gunther Schadow --- Created attachment 219985 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=219985&action=edit the patch as a separate file -- 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 251347] NFS hangs on client side when mounted from outside in Jail Tree (BROKEN NFS SERVER OR MIDDLEWARE)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251347 --- Comment #8 from Rick Macklem --- Ok, I took a quick look and I don't think an NFS mount within a vnet jail is going to work. When the kernel RPC does a socreate() it passes the argument cred as curthread->cred. If this is done by an nfsiod thread, the credential won't be for the correct vnet. This can be fixed by adding cred arguments to assorted functions so that the credential used at mount time can be passed in, but the fix is not trivial. I've never used a vnet jail, so there might be other issues. Sorry, but the short answer is that you will need to figure out a way to do what you are doing without an NFS mount in a vnet jail, I think. I'll take this bug, but don't expect a quick fix. -- 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 251347] NFS hangs on client side when mounted from outside in Jail Tree (BROKEN NFS SERVER OR MIDDLEWARE)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251347 --- Comment #9 from Arne Steinkamm --- (In reply to Rick Macklem from comment #8) Yes, we know that NFS does not work from inside a jail. This is the reason using NULLFS is best practice for years now to give a jail (vnet or not) access to a NFS mount point. The real NFS mountpoint is outside the jail. And nullfs should cover this. Or? And: I have no idea what the freeze triggers... I simulate heavy (!) load from inside the jail and it works up to ca. one hour and tons of gigabyte without problems... Really, the answer can't be to use a fuse'ed NTFS filesystem to share mountpoints between two FreeBSD server... -- 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 251149] SynPS/2 Synaptics TouchPad: Failed to create a device for ... after upgrade from 12.1 to 12.2
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251149
--- Comment #7 from Jens Grassel ---
Hi,
reading about the successful solutions with setting `kern.evdev.rcpt_mask = 3`
I tried again but with no success.
The only thing I can get working with that setting is the console mouse (via
moused) which works as expected but under X it does not work and the error
message in the logs ("... was rejected") stays the same. :-(
Kind regards,
Jens
--
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 251395] rc.d/nfsclient: hangs at shutdown because of non-empty /var/db/mounttab
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251395 Bug ID: 251395 Summary: rc.d/nfsclient: hangs at shutdown because of non-empty /var/db/mounttab Product: Base System Version: 12.2-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: d8zne...@aon.at Scenario: - multiple machines using NFS and autofs (automount) - some of them running FreeBSD 12.2, the others 12.1 - at the end of the day they are shut down simultaneously; before that, it is ensured that all NFS mounts are unmounted (using automount -u and checking via "df -t nfs") Result: - The 12.2 machine hangs in the rc.d/nfsclient script with repeated error messages indicating it cannot contact the remote portmapper: the remote portmapper does not reply anymore because that machine is also going down. - This happens because the file /var/db/mounttab is non-empty and still indicates the remote NFS servers despite the fact that all NFS mounts have already been unmounted. Expected result: - After the last NFS mount from a server has been unmounted, the corresponding entry in /var/db/mounttab, and the complete file if empty, should be removed. - This should enable rc.d/nfsclient to skip any further NFS server notification during shutdown. -- Martin -- 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"
