Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Tue, Aug 07, 2018 at 11:50:44AM -0500, Kyle Evans wrote: > On Tue, Aug 7, 2018 at 12:09 AM, Eitan Adler wrote: > > On Mon, 6 Aug 2018 at 11:27, Kyle Evans wrote: > >> > >> On Sun, Aug 5, 2018 at 5:43 AM, Konstantin Belousov > >> wrote: > >> > On Sat, Aug 04, 2018 at 09:46:39PM -0500, Kyle Evans wrote: > >> >> > >> >> He now gets a little further, but ends up with the same panic due to > >> >> efirtc_probe trying to get time to verify the rtc's actually > >> >> implemented. What kind of approach must we take to ensure curcpu is > >> >> synced? > >> > > >> > It does not panic for me, when I load efirt.ko from the loader prompt. > >> > Anyway, try this > >> > >> Right, I also don't get a panic on any of my machines from this. > >> Hopefully he'll have a chance to try this soon. > > > > This change has no impact: it still panics in the same way as without the > > patch. > > > > That seems indicative of a bigger problem, since we use proc0 > throughout all these bits so we should still be dealing with the same > pmap that got passed to pmap_pinit0 when we grab > curthread->td_proc->p_vmspace->vm_pmap. Can you confirm that you get the early efi_enter() call from rtc code, when you preload the module or compile it into the kernel ? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: programs like gdb core dump
Hi, On Tue, 7 Aug 2018 11:59:11 -0700 John Baldwin wrote: > On 8/6/18 8:11 PM, Erich Dollansky wrote: > > On Mon, 6 Aug 2018 15:57:53 -0700 > > John Baldwin wrote: > > > >> On 8/4/18 4:38 PM, Erich Dollansky wrote: > >>> Bad system call (core dumped) > >> > >> Did you upgrade from stable/11 with a world that is still > >> stable/11? If so, did you make sure your kernel config includes > >> COMPAT_FREEBSD11? (GENERIC should include this) > >> > > > > I never have had a machine running 11. This machine is on 12 since > > 2 or 3 years. I will check if this configuration was properly set > > on that machine. > > Ahh, a fairly old 12 world with a recent 12 kernel will still need > COMPAT_FREEBSD11. > even when kernel and world are on '1200076' as provided by uname -U/-K, COMPAT_FREEBSD11 is required at the moment. The system is currently on r337343. Thanks! Erich ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Wed, Aug 08, 2018 at 01:42:07AM +0300, Konstantin Belousov wrote:
| On Tue, Aug 07, 2018 at 02:49:10PM -0700, Doug Ambrisko wrote:
| > On Tue, Aug 07, 2018 at 08:29:49PM +0300, Konstantin Belousov wrote:
| > | On Tue, Aug 07, 2018 at 11:50:44AM -0500, Kyle Evans wrote:
| > | > On Tue, Aug 7, 2018 at 12:09 AM, Eitan Adler wrote:
| > | > > On Mon, 6 Aug 2018 at 11:27, Kyle Evans wrote:
| > | > >>
| > | > >> On Sun, Aug 5, 2018 at 5:43 AM, Konstantin Belousov
wrote:
| > | > >> > On Sat, Aug 04, 2018 at 09:46:39PM -0500, Kyle Evans wrote:
| > | > >> >>
| > | > >> >> He now gets a little further, but ends up with the same panic due
to
| > | > >> >> efirtc_probe trying to get time to verify the rtc's actually
| > | > >> >> implemented. What kind of approach must we take to ensure curcpu
is
| > | > >> >> synced?
| > | > >> >
| > | > >> > It does not panic for me, when I load efirt.ko from the loader
prompt.
| > | > >> > Anyway, try this
| > | > >>
| > | > >> Right, I also don't get a panic on any of my machines from this.
| > | > >> Hopefully he'll have a chance to try this soon.
| > | > >
| > | > > This change has no impact: it still panics in the same way as without
the patch.
| > | > >
| > | >
| > | > That seems indicative of a bigger problem, since we use proc0
| > | > throughout all these bits so we should still be dealing with the same
| > | > pmap that got passed to pmap_pinit0 when we grab
| > | > curthread->td_proc->p_vmspace->vm_pmap.
| > |
| > | Can you confirm that you get the early efi_enter() call from rtc code,
| > | when you preload the module or compile it into the kernel ?
| >
| > When I ran into this, I did this change:
| >
| > Index: dev/efidev/efirt.c
| > ===
| > --- dev/efidev/efirt.c (revision 337264)
| > +++ dev/efidev/efirt.c (working copy)
| > @@ -257,7 +257,8 @@
| > if (efi_runtime == NULL)
| > return (ENXIO);
| > td = curthread;
| > - curpmap = >td_proc->p_vmspace->vm_pmap;
| > +// curpmap = >td_proc->p_vmspace->vm_pmap;
| > + curpmap = PCPU_GET(curpmap);
| > PMAP_LOCK(curpmap);
| > mtx_lock(_lock);
| > fpu_kern_enter(td, NULL, FPU_KERN_NOCTX);
| > @@ -272,7 +273,8 @@
| >
| > efi_arch_leave();
| >
| > - curpmap = >p_vmspace->vm_pmap;
| > +// curpmap = >p_vmspace->vm_pmap;
| > + curpmap = PCPU_GET(curpmap);
| > td = curthread;
| > fpu_kern_leave(td, NULL);
| > mtx_unlock(_lock);
| >
| > Don't know if it is right. Some previous code used both
| > curpmap = PCPU_GET(curpmap);
| > and
| > curpmap = >td_proc->p_vmspace->vm_pmap;
| > recently it was changes to only use
| > curpmap = >td_proc->p_vmspace->vm_pmap;
| >
| > Things seem to work after that. I was able to repro. it with
| > qemu-system-x86_64 in UEFI mode. I think it also failed in
| > bhyve UEFI mode.
|
| The pcpu curpmap and curproc vmspace pmap should be synced. Esp. since
| there is code relying on this early. I do not want to paper it over.
|
| In fact, try this please. Ignore my previous change.
|
| diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
| index 572b2197453..4bce36cc0e5 100644
| --- a/sys/amd64/amd64/pmap.c
| +++ b/sys/amd64/amd64/pmap.c
| @@ -7536,7 +7536,8 @@ pmap_activate_sw(struct thread *td)
| PCPU_SET(kcr3, pmap->pm_cr3);
| PCPU_SET(ucr3, pmap->pm_ucr3);
| }
| - }
| + } else
| + PCPU_SET(curpmap, pmap);
| if (pmap->pm_ucr3 != PMAP_NO_CR3) {
| rsp0 = ((vm_offset_t)PCPU_PTR(pti_stack) +
| PC_PTI_STACK_SZ * sizeof(uint64_t)) & ~0xful;
That works for qemu and bhyve booting in UEFI PXE mode. I backed
out my other change and synced to head.
Thanks,
Doug A.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Tue, Aug 07, 2018 at 02:49:10PM -0700, Doug Ambrisko wrote:
> On Tue, Aug 07, 2018 at 08:29:49PM +0300, Konstantin Belousov wrote:
> | On Tue, Aug 07, 2018 at 11:50:44AM -0500, Kyle Evans wrote:
> | > On Tue, Aug 7, 2018 at 12:09 AM, Eitan Adler wrote:
> | > > On Mon, 6 Aug 2018 at 11:27, Kyle Evans wrote:
> | > >>
> | > >> On Sun, Aug 5, 2018 at 5:43 AM, Konstantin Belousov
> wrote:
> | > >> > On Sat, Aug 04, 2018 at 09:46:39PM -0500, Kyle Evans wrote:
> | > >> >>
> | > >> >> He now gets a little further, but ends up with the same panic due to
> | > >> >> efirtc_probe trying to get time to verify the rtc's actually
> | > >> >> implemented. What kind of approach must we take to ensure curcpu is
> | > >> >> synced?
> | > >> >
> | > >> > It does not panic for me, when I load efirt.ko from the loader
> prompt.
> | > >> > Anyway, try this
> | > >>
> | > >> Right, I also don't get a panic on any of my machines from this.
> | > >> Hopefully he'll have a chance to try this soon.
> | > >
> | > > This change has no impact: it still panics in the same way as without
> the patch.
> | > >
> | >
> | > That seems indicative of a bigger problem, since we use proc0
> | > throughout all these bits so we should still be dealing with the same
> | > pmap that got passed to pmap_pinit0 when we grab
> | > curthread->td_proc->p_vmspace->vm_pmap.
> |
> | Can you confirm that you get the early efi_enter() call from rtc code,
> | when you preload the module or compile it into the kernel ?
>
> When I ran into this, I did this change:
>
> Index: dev/efidev/efirt.c
> ===
> --- dev/efidev/efirt.c(revision 337264)
> +++ dev/efidev/efirt.c(working copy)
> @@ -257,7 +257,8 @@
> if (efi_runtime == NULL)
> return (ENXIO);
> td = curthread;
> - curpmap = >td_proc->p_vmspace->vm_pmap;
> +// curpmap = >td_proc->p_vmspace->vm_pmap;
> + curpmap = PCPU_GET(curpmap);
> PMAP_LOCK(curpmap);
> mtx_lock(_lock);
> fpu_kern_enter(td, NULL, FPU_KERN_NOCTX);
> @@ -272,7 +273,8 @@
>
> efi_arch_leave();
>
> - curpmap = >p_vmspace->vm_pmap;
> +// curpmap = >p_vmspace->vm_pmap;
> + curpmap = PCPU_GET(curpmap);
> td = curthread;
> fpu_kern_leave(td, NULL);
> mtx_unlock(_lock);
>
> Don't know if it is right. Some previous code used both
> curpmap = PCPU_GET(curpmap);
> and
> curpmap = >td_proc->p_vmspace->vm_pmap;
> recently it was changes to only use
> curpmap = >td_proc->p_vmspace->vm_pmap;
>
> Things seem to work after that. I was able to repro. it with
> qemu-system-x86_64 in UEFI mode. I think it also failed in
> bhyve UEFI mode.
The pcpu curpmap and curproc vmspace pmap should be synced. Esp. since
there is code relying on this early. I do not want to paper it over.
In fact, try this please. Ignore my previous change.
diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
index 572b2197453..4bce36cc0e5 100644
--- a/sys/amd64/amd64/pmap.c
+++ b/sys/amd64/amd64/pmap.c
@@ -7536,7 +7536,8 @@ pmap_activate_sw(struct thread *td)
PCPU_SET(kcr3, pmap->pm_cr3);
PCPU_SET(ucr3, pmap->pm_ucr3);
}
- }
+ } else
+ PCPU_SET(curpmap, pmap);
if (pmap->pm_ucr3 != PMAP_NO_CR3) {
rsp0 = ((vm_offset_t)PCPU_PTR(pti_stack) +
PC_PTI_STACK_SZ * sizeof(uint64_t)) & ~0xful;
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Unkillable linux processes
Hi I seem to have some unkillable Linux processes... This is on my AMD Ryzen, the exact same installation on my Broadwell laptop does not show this behavior. At the second top output, the three remaining processes' cpu usage is fluctuating, just as when they are running normally. Kernel is from one or two days ago with kib's patch that I got the other day. root@amd:~ # top PID USERNAMETHR PRI NICE SIZERES STATEC TIMEWCPU COMMAND 978 boinc 3 155 i31 129M64M futex3 0:52 100.74% wcgrid_zika_vina_7. 979 boinc 3 155 i31 112M47M futex2 0:56 99.24% wcgrid_oet1_vina_7. 980 boinc 2 155 i31 150M87M CPU3 3 0:46 97.66% wcgrid_mip1_rosetta 977 boinc 3 155 i31 109M43M futex1 0:56 97.39% wcgrid_oet1_vina_7. root@amd:~ # service boinc-client stop Stopping boinc_client. Waiting for PIDS: 892. root@amd:~ # top last pid: 1003; load averages: 3.18, 2.04, 0.94 up 0+00:05:31 20:48:06 25 processes: 1 running, 21 sleeping, 3 stopped CPU: 0.0% user, 0.0% nice, 73.8% system, 0.0% interrupt, 26.2% idle Mem: 157M Active, 2736K Inact, 300M Wired, 162M Buf, 2907M Free Swap: PID USERNAMETHR PRI NICE SIZERES STATEC TIMEWCPU COMMAND 977 boinc 2 20 i31 110M44M STOP 0 3:57 100.00% wcgrid_oet1_vina_7. 979 boinc 2 20 i31 113M47M STOP 0 3:54 97.02% wcgrid_oet1_vina_7. 978 boinc 2 20 i31 130M64M STOP 0 3:50 96.12% wcgrid_zika_vina_7. root@amd:~ # procstat -ak | grep wcgrid 977 100162 wcgrid_oet1_vina_7. - mi_switch thread_suspend_switch thread_single exit1 linux_exit_group ia32_syscall int0x80_syscall_common 977 100172 wcgrid_oet1_vina_7. - witness_checkorder __mtx_lock_flags linux_sys_futex ia32_syscall int0x80_syscall_common 978 100163 wcgrid_zika_vina_7. - mi_switch thread_suspend_switch thread_single exit1 linux_exit_group ia32_syscall int0x80_syscall_common 978 100174 wcgrid_zika_vina_7. - __mtx_lock_flags futex_put linux_sys_futex ia32_syscall int0x80_syscall_common 979 100132 wcgrid_oet1_vina_7. - mi_switch thread_suspend_switch thread_single exit1 linux_exit_group ia32_syscall int0x80_syscall_common 979 100171 wcgrid_oet1_vina_7. - linux_sys_futex ia32_syscall int0x80_syscall_common ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: programs like gdb core dump
On 8/6/18 8:11 PM, Erich Dollansky wrote: > Hi, > > On Mon, 6 Aug 2018 15:57:53 -0700 > John Baldwin wrote: > >> On 8/4/18 4:38 PM, Erich Dollansky wrote: >>> Hi, >>> >>> I compiled me yesterday this system: >>> >>> 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r337285: >>> >>> When restarting fortune core dumps. When trying to load the core >>> dump, gdb core dumps. >>> >>> The message is always: >>> >>> Bad system call (core dumped) >>> >>> Trying to install ports results in the same effect. >>> >>> Erich >> >> Did you upgrade from stable/11 with a world that is still stable/11? >> If so, did you make sure your kernel config includes COMPAT_FREEBSD11? >> (GENERIC should include this) >> > > I never have had a machine running 11. This machine is on 12 since 2 or > 3 years. I will check if this configuration was properly set on that > machine. Ahh, a fairly old 12 world with a recent 12 kernel will still need COMPAT_FREEBSD11. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Tue, Aug 07, 2018 at 08:29:49PM +0300, Konstantin Belousov wrote: | On Tue, Aug 07, 2018 at 11:50:44AM -0500, Kyle Evans wrote: | > On Tue, Aug 7, 2018 at 12:09 AM, Eitan Adler wrote: | > > On Mon, 6 Aug 2018 at 11:27, Kyle Evans wrote: | > >> | > >> On Sun, Aug 5, 2018 at 5:43 AM, Konstantin Belousov wrote: | > >> > On Sat, Aug 04, 2018 at 09:46:39PM -0500, Kyle Evans wrote: | > >> >> | > >> >> He now gets a little further, but ends up with the same panic due to | > >> >> efirtc_probe trying to get time to verify the rtc's actually | > >> >> implemented. What kind of approach must we take to ensure curcpu is | > >> >> synced? | > >> > | > >> > It does not panic for me, when I load efirt.ko from the loader prompt. | > >> > Anyway, try this | > >> | > >> Right, I also don't get a panic on any of my machines from this. | > >> Hopefully he'll have a chance to try this soon. | > > | > > This change has no impact: it still panics in the same way as without the patch. | > > | > | > That seems indicative of a bigger problem, since we use proc0 | > throughout all these bits so we should still be dealing with the same | > pmap that got passed to pmap_pinit0 when we grab | > curthread->td_proc->p_vmspace->vm_pmap. | | Can you confirm that you get the early efi_enter() call from rtc code, | when you preload the module or compile it into the kernel ? When I ran into this, I did this change: Index: dev/efidev/efirt.c === --- dev/efidev/efirt.c (revision 337264) +++ dev/efidev/efirt.c (working copy) @@ -257,7 +257,8 @@ if (efi_runtime == NULL) return (ENXIO); td = curthread; - curpmap = >td_proc->p_vmspace->vm_pmap; +// curpmap = >td_proc->p_vmspace->vm_pmap; + curpmap = PCPU_GET(curpmap); PMAP_LOCK(curpmap); mtx_lock(_lock); fpu_kern_enter(td, NULL, FPU_KERN_NOCTX); @@ -272,7 +273,8 @@ efi_arch_leave(); - curpmap = >p_vmspace->vm_pmap; +// curpmap = >p_vmspace->vm_pmap; + curpmap = PCPU_GET(curpmap); td = curthread; fpu_kern_leave(td, NULL); mtx_unlock(_lock); Don't know if it is right. Some previous code used both curpmap = PCPU_GET(curpmap); and curpmap = >td_proc->p_vmspace->vm_pmap; recently it was changes to only use curpmap = >td_proc->p_vmspace->vm_pmap; Things seem to work after that. I was able to repro. it with qemu-system-x86_64 in UEFI mode. I think it also failed in bhyve UEFI mode. Thanks, Doug A. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Unkillable linux processes
On Tue, Aug 07, 2018 at 08:54:39PM +0100, Johannes Lundberg wrote: > Hi > > I seem to have some unkillable Linux processes... > This is on my AMD Ryzen, the exact same installation on my Broadwell laptop > does not show this behavior. > At the second top output, the three remaining processes' cpu usage is > fluctuating, just as when they are running normally. > Kernel is from one or two days ago with kib's patch that I got the other > day. Exactly which patch ? There was a followup to the initial change. Both are committed as of r337431. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Unkillable linux processes
On Tue, Aug 7, 2018 at 21:16 Konstantin Belousov wrote: > On Tue, Aug 07, 2018 at 08:54:39PM +0100, Johannes Lundberg wrote: > > Hi > > > > I seem to have some unkillable Linux processes... > > This is on my AMD Ryzen, the exact same installation on my Broadwell > laptop > > does not show this behavior. > > At the second top output, the three remaining processes' cpu usage is > > fluctuating, just as when they are running normally. > > Kernel is from one or two days ago with kib's patch that I got the other > > day. > Exactly which patch ? There was a followup to the initial change. > > Both are committed as of r337431. Ok. I will try a new fresh kernel build tomorrow. Thanks! > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ffs_truncate3 panics
Hi, During testing of the pNFS server I get an ffs_truncate3 panic every once in a while. A few things that might be relevant: - Seems to happen more often when soft update journaling is enabled, but will happen when it is disabled. - Normally happens when a fairly large subtree of the file system is being removed. These file systems are a bit odd, since all the regular files in them are empty but have extended attributes that are accessed during the subtree removal. (The extended attributes tell the server where the data files are.) I replaced the panic() with a printf() and every time the printf() happens... bo->bo_dirty.bv_cnt == 0 and bo->bo_clean.bv_cnt == 1. After one of these printf()s, the system continues to run ok. When the file system is fsck'd after this has occurred, it passes fine and I haven't seen and indication of file system corruption after running with this file system for quite a while after the printf()s first occurred. Since the panic() only occurs when "options INVARIANTS" is enabled and I don't see evidence of file system corruption, I'm wondering if this panic() is valid and needed? rick ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Need to reserve Intel graphics memory in early boot
On Tue, Aug 07, 2018 at 09:04:57AM +0100, Johannes Lundberg wrote: > Hi > > I'm working on getting the graphics drivers up to Linux 4.16 version and > there has been a patch for Intel gpus that require some code in early boot. > > The problem is that no all bios report the memory allocated for the gpu, > called stolen memory, correctly so on some configurations the OS can > reclaim this memory during boot that thus it's not accessible to the gpu > driver (at least that is my understanding). Drivers need the stolen memory > for frame buffer compression (fbc) to work (maybe more features as well > depend on stolen memory). The purpose of fbc is to reduce power consumption. > > So, what we need to do is get the base and size of the stolen memory and > reserve it before the OS have a chance to claim it. This information will > be stored in a global variable that the drm i915 driver can later read. > > The Linux implementation can be found here: > https://elixir.bootlin.com/linux/v4.16/source/arch/x86/kernel/early-quirks.c#L539 > > The drm and i915 driver code are dual licensed but I'm not sure about the > code in the file above, it might be GPL only. > > Anyone feeling up to doing this? Or if you have any pointers as to where > would be a good place to implement this in FreeBSD, I can give it a shot. Most likely what you need is to exclude the range from the phys_avail[] array. Look at the amd64/machdep.c how this array is handled by early startup. Another option might be to not exclude the pages from phys_avail[], but instead use vm_page_blacklist_add() function to reserve some pages. The difference with phys_avail[] approach is that blacklist_add can be done somewhat later, after VM subsystem consumed phys_avail[] and initialized the structures to describe the page frames. Depending on the fbc code, it might be more convenient to have vm_page_t describing the stolen memory, but the drawback is that it can be done later in boot process, and depending on the location of the stolen mem, other kernel subsystem might already carved some pages from it. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
declient without capsicum failes
hi, latest change to dhclient added chroot if there is no capsicum - my case, so chroot failes because /var/empty belongs to root and setgid/setgid/seteuid to user dhclient is performed before. need a pr? danny ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Need to reserve Intel graphics memory in early boot
Hi I'm working on getting the graphics drivers up to Linux 4.16 version and there has been a patch for Intel gpus that require some code in early boot. The problem is that no all bios report the memory allocated for the gpu, called stolen memory, correctly so on some configurations the OS can reclaim this memory during boot that thus it's not accessible to the gpu driver (at least that is my understanding). Drivers need the stolen memory for frame buffer compression (fbc) to work (maybe more features as well depend on stolen memory). The purpose of fbc is to reduce power consumption. So, what we need to do is get the base and size of the stolen memory and reserve it before the OS have a chance to claim it. This information will be stored in a global variable that the drm i915 driver can later read. The Linux implementation can be found here: https://elixir.bootlin.com/linux/v4.16/source/arch/x86/kernel/early-quirks.c#L539 The drm and i915 driver code are dual licensed but I'm not sure about the code in the file above, it might be GPL only. Anyone feeling up to doing this? Or if you have any pointers as to where would be a good place to implement this in FreeBSD, I can give it a shot. Cheers ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: programs like gdb core dump
Hi, On Tue, 7 Aug 2018 00:09:15 -0400 Allan Jude wrote: > On 2018-08-06 23:11, Erich Dollansky wrote: > >>> The message is always: > >>> > >>> Bad system call (core dumped) > > compare the output of: `uname -K` and `uname -U` > both outputs are 1200076 I got just access to that machine again. I will check it configuration. Erich ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
zpool scrub. Wtf?
# zpool status pool: zroot state: ONLINE scan: scrub in progress since Tue Aug 7 21:21:51 2018 804G scanned at 163M/s, 1,06T issued at 219M/s, 834G total 0 repaired, 129,87% done, 929637 days 13:43:01 to go config: NAMESTATE READ WRITE CKSUM zroot ONLINE 0 0 0 ada0p4ONLINE 0 0 0 errors: No known data errors smart is OK FreeBSD 12.0-CURRENT #3 r337364: Mon Aug 6 07:01:42 +07 2018 amd64 -- - Alex. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Vbox causing host crash/reboot on 12-current
Update: I found the revision: https://svnweb.freebsd.org/base?view=revision=336876 Use SMAP on amd64. Could this possibly cause VBox to crash and reboot the system? Is there a sysctl to disable? Thanks On Tue, Aug 7, 2018 at 10:46 AM, AN wrote: > I recently started having severe instability on a workstation with > VirtualBox. I'm not sure if it was caused by the recent large ports > update, or a recent commit that affected SMAP. I can't seem to find > that revision, would someone please post it and also the workaround to > disable it, I would like to try it after work and see if disabling it > allows VBox to work. Is anyone else seeing this effect with Vbox? > > What I'm seeing is that as soon as a VM is started it reboots the > host, totally reproducible every time. I tried to rebuild VBox and > kmod, and also some qt5 ports but still not working. Any help is > appreciated, thanks for reading. > > Regards ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Vbox causing host crash/reboot on 12-current
I recently started having severe instability on a workstation with VirtualBox. I'm not sure if it was caused by the recent large ports update, or a recent commit that affected SMAP. I can't seem to find that revision, would someone please post it and also the workaround to disable it, I would like to try it after work and see if disabling it allows VBox to work. Is anyone else seeing this effect with Vbox? What I'm seeing is that as soon as a VM is started it reboots the host, totally reproducible every time. I tried to rebuild VBox and kmod, and also some qt5 ports but still not working. Any help is appreciated, thanks for reading. Regards ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: install: auto_master: No such file or directory
Alan Somers wrote this message on Sun, Aug 05, 2018 at 11:35 -0600: > On Sun, Aug 5, 2018 at 5:39 AM, Jeffrey Bouquet > wrote: > > > > > > > On Sun, 5 Aug 2018 03:19:48 +0200, Lars Schotte wrote: > > > > > somehow installworld fails lately > > > > > > ===> share/examples (install) > > > if [ -L /usr/share/examples/BSD_daemon ]; then rm -f > > /usr/share/examples/BSD_daemon; fi > > > if [ -L /usr/share/examples/FreeBSD_version ]; then rm -f > > /usr/share/examples/FreeBSD_version; fi > > > if [ -L /usr/share/examples/IPv6 ]; then rm -f > > /usr/share/examples/IPv6; fi > > > if [ -L /usr/share/examples/bootforth ]; then rm -f > > /usr/share/examples/bootforth; fi > > > if [ -L /usr/share/examples/csh ]; then rm -f /usr/share/examples/csh; > > fi > > > if [ -L /usr/share/examples/diskless ]; then rm -f > > /usr/share/examples/diskless; fi > > > if [ -L /usr/share/examples/drivers ]; then rm -f > > /usr/share/examples/drivers; fi > > > if [ -L /usr/share/examples/etc ]; then rm -f /usr/share/examples/etc; > > fi > > > if [ -L /usr/share/examples/find_interface ]; then rm -f > > /usr/share/examples/find_interface; fi > > > if [ -L /usr/share/examples/ibcs2 ]; then rm -f > > /usr/share/examples/ibcs2; fi > > > if [ -L /usr/share/examples/indent ]; then rm -f > > /usr/share/examples/indent; fi > > > if [ -L /usr/share/examples/ipfw ]; then rm -f > > /usr/share/examples/ipfw; fi > > > if [ -L /usr/share/examples/jails ]; then rm -f > > /usr/share/examples/jails; fi > > > if [ -L /usr/share/examples/kld ]; then rm -f /usr/share/examples/kld; > > fi > > > if [ -L /usr/share/examples/libvgl ]; then rm -f > > /usr/share/examples/libvgl; fi > > > if [ -L /usr/share/examples/mdoc ]; then rm -f > > /usr/share/examples/mdoc; fi > > > if [ -L /usr/share/examples/netgraph ]; then rm -f > > /usr/share/examples/netgraph; fi > > > if [ -L /usr/share/examples/perfmon ]; then rm -f > > /usr/share/examples/perfmon; fi > > > if [ -L /usr/share/examples/ppi ]; then rm -f /usr/share/examples/ppi; > > fi > > > if [ -L /usr/share/examples/ppp ]; then rm -f /usr/share/examples/ppp; > > fi > > > if [ -L /usr/share/examples/printing ]; then rm -f > > /usr/share/examples/printing; fi > > > if [ -L /usr/share/examples/ses ]; then rm -f /usr/share/examples/ses; > > fi > > > if [ -L /usr/share/examples/scsi_target ]; then rm -f > > /usr/share/examples/scsi_target; fi > > > if [ -L /usr/share/examples/sunrpc ]; then rm -f > > /usr/share/examples/sunrpc; fi > > > if [ -L /usr/share/examples/ypldap ]; then rm -f > > /usr/share/examples/ypldap; fi > > > if [ -L /usr/share/examples/bhyve ]; then rm -f > > /usr/share/examples/bhyve; fi > > > if [ -L /usr/share/examples/uefisign ]; then rm -f > > /usr/share/examples/uefisign; fi > > > if [ -L /usr/share/examples/hast ]; then rm -f > > /usr/share/examples/hast; fi > > > if [ -L /usr/share/examples/libusb20 ]; then rm -f > > /usr/share/examples/libusb20; fi > > > (cd /usr/src/etc; make MK_MAKE_CHECK_USE_SANDBOX=yes etc-examples) > > > cd /usr/src/etc; install -o root -g wheel -m 444 crontab devd.conf > > devfs.conf ddb.conf dhclient.conf disktab fbtab gettytab group > > hosts hosts.allow hosts.equiv libalias.conf libmap.conf login.access > > login.conf mac.conf motd netconfig networks newsyslog.conf > > nsswitch.conf phones profile protocols rc.bsdextended rc.firewall > > remote rpc services sysctl.conf syslog.conf termcap.small > > etc.amd64/ttys amd.map auto_master ftpusers inetd.conf > > /usr/src/usr.bin/locate/locate/locate.rc hosts.lpd printcap > > /usr/src/usr.bin/mail/misc/mail.rc ntp.conf pf.os rc.sendmail csh.cshrc > > csh.login csh.logout regdomain.xml nsmb.conf opieaccess > > /usr/share/examples/etc > > > install: auto_master: No such file or directory > > > *** Error code 71 > > > > > > Stop. > > > make[6]: stopped in /usr/src/etc > > > *** Error code 1 > > > > > > Stop. > > > make[5]: stopped in /usr/src/share/examples > > > *** Error code 1 > > > > > > Stop. > > > make[4]: stopped in /usr/src/share > > > *** Error code 1 > > > > > > Stop. > > > make[3]: stopped in /usr/src > > > *** Error code 1 > > > > > > Stop. > > > make[2]: stopped in /usr/src > > > *** Error code 1 > > > > > > Stop. > > > make[1]: stopped in /usr/src > > > *** Error code 1 > > > > > > Stop. > > > make: stopped in /usr/src > > > # less UPDATING > > > # svn up > > > Updating '.': > > > At revision 337340. > > > > > > > > > -- > > > Lars Schotte > > > Mudro??ova 13 > > > 92101 Pieany > > > ___ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > > freebsd.org" > > > > > > It's been on my wishlist that buildworld includes a 'fake installworld, > > copying > > /bin /usr/bin subtrees into a chroot or something... ' so if the > > real one fails, where it
Re: declient without capsicum failes
On Tue, Aug 07, 2018 at 03:48:31PM +0300, Daniel Braniss wrote: > hi, > latest change to dhclient added chroot if there is no capsicum - my case, > so chroot failes because /var/empty belongs to root and > setgid/setgid/seteuid to user dhclient is performed before. > > need a pr? Thanks, please try r337415. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ffs_truncate3 panics
On Tue, Aug 07, 2018 at 12:28:33PM +, Rick Macklem wrote: > Hi, > > During testing of the pNFS server I get an ffs_truncate3 panic every once in > a while. > A few things that might be relevant: > - Seems to happen more often when soft update journaling is enabled, but will > happen when it is disabled. > - Normally happens when a fairly large subtree of the file system is being > removed. > > These file systems are a bit odd, since all the regular files in them are > empty but > have extended attributes that are accessed during the subtree removal. (The > extended attributes tell the server where the data files are.) > > I replaced the panic() with a printf() and every time the printf() happens... > bo->bo_dirty.bv_cnt == 0 and bo->bo_clean.bv_cnt == 1. > After one of these printf()s, the system continues to run ok. When the file > system is fsck'd after this has occurred, it passes fine and I haven't seen > and > indication of file system corruption after running with this file system for > quite a while after the printf()s first occurred. The lack of corruption is, most likely, because the files are removed. Would the files truncated to zero length and then extended, I am almost sure that a corruption occur. Can you print the only buffer on the clean queue when the panic occur ? Also, it is interesting to know the initial length of the file. > > Since the panic() only occurs when "options INVARIANTS" is enabled and I don't > see evidence of file system corruption, I'm wondering if this panic() is > valid and > needed? > > rick > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Tue, Aug 7, 2018 at 12:09 AM, Eitan Adler wrote: > On Mon, 6 Aug 2018 at 11:27, Kyle Evans wrote: >> >> On Sun, Aug 5, 2018 at 5:43 AM, Konstantin Belousov >> wrote: >> > On Sat, Aug 04, 2018 at 09:46:39PM -0500, Kyle Evans wrote: >> >> >> >> He now gets a little further, but ends up with the same panic due to >> >> efirtc_probe trying to get time to verify the rtc's actually >> >> implemented. What kind of approach must we take to ensure curcpu is >> >> synced? >> > >> > It does not panic for me, when I load efirt.ko from the loader prompt. >> > Anyway, try this >> >> Right, I also don't get a panic on any of my machines from this. >> Hopefully he'll have a chance to try this soon. > > This change has no impact: it still panics in the same way as without the > patch. > That seems indicative of a bigger problem, since we use proc0 throughout all these bits so we should still be dealing with the same pmap that got passed to pmap_pinit0 when we grab curthread->td_proc->p_vmspace->vm_pmap. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
