isable-module, toggle-module and show-module-options should be present
(defined in /boot/lua/cli.lua). I am also pretty sure, Kyle did add those when
13 was current, lua version was missing those, Forth version had them first:)
rgds,
toomas
On 20. Oct 2022, at 13:27, Andriy Gapon <mailto:a...@fr
Sent from my iPhone
On 20. Oct 2022, at 13:08, Emmanuel Vadot wrote:
On Thu, 20 Oct 2022 13:03:26 +0300
Andriy Gapon wrote:
I recently needed to recover a system by manually preloading a driver.
To a bit of surprise, simple 'load $modname' did not work, I had to use 'load
/boot/kernel
!
--
Andriy Gapon
to be
complete. The effect of addresses is under-described and I do not see any
mention of credentials (UIDs).
Is there a way to tell if some behavior is correct or not?
Is it all in heads of people and in the change history?
On 04/10/2022 14:46, Andriy Gapon wrote:
On 04/10/2022 14:37, Sean
Sorry that it took a while.
I cannot reproduce the problem after applying the patch.
I see that you already committed the change, but I thought that I'd let you
know.
Thank you very much!
--
Andriy Gapon
() at 0x808b662a = ithread_loop+0x2da/frame
0xfe003590eef0
fork_exit() at 0x808b2f85 = fork_exit+0xc5/frame 0xfe003590ef30
fork_trampoline() at 0x80c084fe = fork_trampoline+0xe/frame
0xfe003590ef30
--
Andriy Gapon
r you override it via vfs.root.mountfrom,
then you should know what you do and why.
At the very least, it's an undocumented incompatibility between beadm
and bectl: I can't take an existing system that's using beadm and just
switch to using bectl.
Yeah, but I would blame beadm for doing things
On 2022-07-13 21:33, John Baldwin wrote:
On 7/13/22 3:17 AM, Andriy Gapon wrote:
On 2022-07-13 13:09, Michael Gmelin wrote:
On Wed, 13 Jul 2022 10:29:06 +0300
Andriy Gapon wrote:
# uname -U
1400063
# uname -K
1400063
# pkg upgrade
Updating FreeBSD repository catalogue...
Fetching
On 2022-07-10 20:28, Gleb Smirnoff wrote:
On Thu, Jul 07, 2022 at 03:29:04PM +0300, Andriy Gapon wrote:
A> I have a strange issue with running an 'appliance' image based on
A> FreeBSD 12 in bhyve on a machine with Ryzen 5800x processor.
A>
A> The problem is that the guest would run
On 2022-07-13 13:09, Michael Gmelin wrote:
On Wed, 13 Jul 2022 10:29:06 +0300
Andriy Gapon wrote:
# uname -U
1400063
# uname -K
1400063
# pkg upgrade
Updating FreeBSD repository catalogue...
Fetching packagesite.pkg: 100%5 MiB 4.8MB/s00:01
Processing entries: 0%
Newer FreeBSD
kernel: 1400051
Ignore the mismatch and continue? [y/N]:
Does anyone know why this would happen?
Where does pkg get its notion of the running kernel version?
--
Andriy Gapon
https://standforukraine.com
https://razomforukraine.org
the problem.
Does anyone have an idea what the problem could be?
What workaround or diagnostics to try?
Anybody else seen something like this?
Since it's the host that resets it would be hard to capture any traces.
Thank you.
--
Andriy Gapon
https://standforukraine.com
https://razomforukraine.org
On 04/02/2022 13:23, Daniel Braniss wrote:
On 4 Feb 2022, at 12:07, Andriy Gapon wrote:
It seems that in some cases zpool import -c requires read/write access to the zpool.cache
file. So, it probably makes sense to import "other" pools (non-root) after
upgrading / to rw.
W
It seems that in some cases zpool import -c requires read/write access to the
zpool.cache file. So, it probably makes sense to import "other" pools
(non-root) after upgrading / to rw.
What do you think?
--
Andriy Gapon
On 23/01/2022 07:40, Daniel O'Connor wrote:
It is very strange that devd dying would kill anything else running
Because most likely it's a correlation, not causation.
Many things die and among them devd.
--
Andriy Gapon
disk and an orphan event from the same disk. With only one member left
the mirror may not realize that the ENXIO came from the detached disk, so it may
think that there is no device left to re-try the request.
--
Andriy Gapon
he default pipe sizing
configuration). That contributes to a quick wrap-around of circular buffers.
--
Andriy Gapon
c_sysfs.html
- https://static.linaro.org/connect/lvc21/presentations/lvc21-219.pdf
-
https://uefi.org/specs/ACPI/6.4/14_Platform_Communications_Channel/Platform_Comm_Channel.html
--
Andriy Gapon
ing on ZFS or anything related to ZFS should be
unaffected.
--
Andriy Gapon
a
system crash dump.
But neither does any magic.
The errors will still be there.
--
Andriy Gapon
situation
thoughts ?
Try to update boot blocks. Not sure what you use, like gptzfsboot, etc.
--
Andriy Gapon
On 27/11/2021 10:42, Andriy Gapon wrote:
On 26/11/2021 21:48, Mark Johnston wrote:
On Fri, Nov 26, 2021 at 02:00:27PM -0500, Mark Johnston wrote:
Thanks, I can reproduce it now.
Our libdwarf is complaining that the first compilation unit header in
.debug_info contains an unsupported DWARF
that. As an interim
workaround this could simply be disabled with WITH_CTF is configured:
Oh wow, you were very fast at figuring this out.
Thank you very much!
I'll give the build change a whirl first and then test D33139 a bit later.
--
Andriy Gapon
On 26/11/2021 18:06, Mark Johnston wrote:
On Thu, Nov 25, 2021 at 10:48:36PM +0200, Andriy Gapon wrote:
I've just finished builds of yesterday's CURRENT / main for arm and arm64.
In both builds I got lots of messages from ctfconvert:
ctfconvert: rc = 1 Unsupported version [_dwarf_info_load
.
--
Andriy Gapon
On 10/11/2021 11:30, Andriy Gapon wrote:
On 09/11/2021 17:56, Andriy Gapon wrote:
So, as I was saying, when the delta is large the calculations in tc_windup and
bintime_off give slightly different results and that can lead to a
discontinuity of the time when timehands are switched.
A quick
On 09/11/2021 17:56, Andriy Gapon wrote:
So, as I was saying, when the delta is large the calculations in tc_windup and
bintime_off give slightly different results and that can lead to a discontinuity
of the time when timehands are switched.
A quick follow-up.
I think that both tc_windup
On Tue, Nov 09, 2021 at 11:58:30AM +0200, Andriy Gapon wrote:
Here is an explanation for the numbers reported in the panic message (sorted
from earliest to latest):
190543869603412 - 'now' as seen in sleepq_timeout(), returned by sbinuptime();
190543869738008 - td_sleeptimo, also c_time
eepq_timeout() to get "current time" from
c_exec_time (added by us) instead of sbinuptime(). c_exec_time is the value of
'now' in callout_process() when it decides that the callout should fire.
But I'd like to get to the bottom of the issue.
--
Andriy Gapon
DESTDIR is not honored in some place?
The able is for installing CURRENT on a stable/13 host.
--
Andriy Gapon
://cgit.FreeBSD.org/src/commit/?id=bd84094a51c4648a7c97ececdaccfb30bc832096
--
Andriy Gapon
On 28/08/2021 17:28, Andriy Gapon wrote:
This seems to be related to the recent change to install manual pages for all
platforms.
My method of creating a cross-platform installation image is to install with
NO_ROOT and then to tar up with @METALOG argument.
On the destination I simply untar
/man/man4/powerpc/../akbd.4.gz: Path contains '..'
This is a not a big deal but would be nice to "straighten" the installation
paths when installing such manual pages.
P.S.
NO_ROOT does not seem to be documented outside of the source code.
--
Andriy Gapon
-kmod /usr/local/sys/modules
Now it gets compiled every time you do make buildkernel.
If things break you can do a git pull in the drm-kmod dir
and rebuild.
I did approximately the same, but instead of a symlink I use LOCAL_MODULES_DIR
and LOCAL_MODULES.
--
Andriy Gapon
ERIC-NODBG-CA72
arm64 aarch64 1300139 1300139
Cannot reproduce here (but with much simpler names and on stable/13):
zfs create testz/test
zfs snapshot testz/test@snap1
zfs rename testz/test testz/test2
All worked.
--
Andriy Gapon
___
freebsd-current@f
On 14/04/2021 16:32, Mark Johnston wrote:
On Wed, Apr 14, 2021 at 02:21:44PM +0300, Andriy Gapon wrote:
On 14/04/2021 00:18, Mark Johnston wrote:
fbt::vm_page_unwire:entry
/args[0]->oflags & 0x4/
{
@unwire[stack()] = count();
}
Unrelated report, dtrace complains about thi
oflags type=3 off=760
psind type=2167 off=768
segind type=2167 off=776
valid type=3574 off=784
dirty type=3574 off=792
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman
ate it with any activity.
P.S.
I have not been running any virtual machines.
I do use nvidia graphics driver.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe
On 07/04/2021 22:54, Mark Johnston wrote:
> On Wed, Apr 07, 2021 at 10:42:57PM +0300, Andriy Gapon wrote:
>>
>> I regularly see that the top's memory line does not add up (and by a lot).
>> That can be seen with vm.stats as well.
>>
>> For example:
&
er of pages either.
Approximately 2 million pages, 8 gigabytes or 25% of the whole memory on this
system.
This is 47c00a9835926e96, 13.0-STABLE amd64.
I do not think that I saw anything like that when I used (much) older FreeBSD.
--
Andriy Gapon
___
freebsd-c
hat masks the problem.
So, I guess that DTrace produced traces won't have many clues, if any at all.
I wonder if KTR tracing would be better in this respect.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinf
gt;
> real 0m4,270s
> user 0m0,000s
> sys 0m0,019s
>
> $ time uptime
> 16:20 up 23:23, 4 users, load averages: 0,17 0,39 2,68
>
> real 0m10,840s
> user 0m0,001s
> sys 0m0,374s
>
> $ time uptime
> 16:37 up 23:40, 4 users, load averages:
traces collected
using KTR. The file has instructions on how to collect them.
Alternatively, schedgraph.d can be used to collect such traces.
If anyone affected can gather a short sample that captures the problem, then
there might be someone who would be willing to look at them.
--
Andriy Gapon
_
<-> USB adapter).
Of course, it would be great to reduce the dead window for USB keyboards and I
think that it is doable.
--
Andriy Gapon
___
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"
e ideal to fix the issue in the driver.
--
Andriy Gapon
___
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"
"clear stall" (clearing halt on endpoints)
# CH340 USB<->RS232 requires this
# and it seems that Linux and Windows do this by default
hw.usb.no_cs_fail=1
I recall that without that tuning I had a similar problem.
> вт, 5 июн. 2018 г. в 15:05, Ian FREISLICH :
>
>> On 0
vn_seqc_write_end(ZTOV(attrzp));
> ASSERT(err == 0);
> }
> }
>
> I don't see other calls to the routine.
This patch works perfectly for me.
Thank you!
> On 2/16/21, Andriy Gapon wrote:
>> On 15/02/2021 11:45, Andriy Gapon wrote:
&g
_end_info = 0}}
(kgdb) p *tp@entry->sackhint.nexthole
$8 = {start = 3846396940, end = 3846398380, rxmit = 3846398380, scblink =
{tqe_next = 0x0, tqe_prev = 0xf8013da5a330}}
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebs
On 15/02/2021 11:45, Andriy Gapon wrote:
> On 15/02/2021 10:22, Andriy Gapon wrote:
>>
>> I've got this panic once when copying a couple of files.
>> The system is stable/13 as of 1996360d7338d, a custom kernel configuration,
>> but
>> no local source code mo
On 15/02/2021 10:22, Andriy Gapon wrote:
>
> I've got this panic once when copying a couple of files.
> The system is stable/13 as of 1996360d7338d, a custom kernel configuration,
> but
> no local source code modifications.
>
> Unread portion of the kernel message buff
l/git/trant/sys/kern/vfs_syscalls.c:2962
#12 0x80b25b69 in syscallenter (td=0xfe01dd1cd560)
at /usr/devel/git/trant/sys/amd64/amd64/../../kern/subr_syscall.c:189
#13 0x80b25845 in amd64_syscall (td=0xfe01dd1cd560, traced=0)
at /usr/devel/git/trant/sys/amd64/amd64/trap.c:11
> syscall(4074ece8,3b,3b,3b,2d130d1c,...) at syscall+0x17d/frame 0x4074ecdc
> Xint0x80_syscall() at 0xffc033f9/frame 0x4074ecdc
> --- syscall (881410048), eip = 0x2d086faf, esp = 0xfa1e339c, ebp = 0xfa1e33c8
> ---
> KDB: enter: panic
This is the crash.
The DRM mutex noise is just noise (b
On 2021-01-13 16:13, David Wolfskill wrote:
> On Wed, Jan 13, 2021 at 04:07:35PM +0200, Andriy Gapon wrote:
>> ...
>>> I believe that this is evidence in favor of a "race condition" diagnosis.
>>> (In precisely what, I don't know,)
>>
>> I haven't
On 2021-01-13 16:03, David Wolfskill wrote:
> On Tue, Jan 12, 2021 at 07:37:28AM -0800, David Wolfskill wrote:
>> On Tue, Jan 12, 2021 at 05:31:30PM +0200, Andriy Gapon wrote:
>>> On 2021-01-11 14:55, David Wolfskill wrote:
>>>> pci3: unknown notify 0x2
>>&g
-to-sleep) failure.
> ACPI Error: Aborting method \_PTS due to previous error (AE_NO_MEMORY)
> (20201113/psparse-689)
> acpi0: AcpiEnterSleepStatePrep failed - AE_NO_MEMORY
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https:/
On 2020-12-29 17:11, monochrome wrote:
> ok, this appears to be what I was looking for
>
> example:
> git reset --hard f20c0e331
> then:
> git pull --ff-only
> is again able to update as normal
>
> I should point out also that this is from the point of view of any
> random person just building
On 2020-12-29 02:56, Pete Wright wrote:
>
> On 12/28/20 4:38 PM, monochrome wrote:
>> what would be the git command for reverting source to a previous
>> version using these numbers? for example, with svn and old numbers:
>> svnlite update -r367627 /usr/src
>>
> I will generally just checkout the
increase?
There might be a bug in pvscsi where it does not respect or correctly advertise
some limit. There could be a similar issue with VMware itself (its emulation of
a disk / target).
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http
s of bogus results (with respect to
randomness) or unsafe as in may crash?
> On Wed, Dec 2, 2020 at 13:53 Andriy Gapon <mailto:a...@freebsd.org>> wrote:
>
>
> Specifically, concurrent "first" calls to rand().
> There can be a moment when r
(from ZFS).
I guess that it uses rand() just because that's what OpenZFS did / does on
illumos and Linux.
P.P.S.
Just realized that the problem can be relatively recent.
https://svnweb.freebsd.org/base?view=revision=357382
--
Andriy Gapon
___
freeb
On 02/12/2020 18:52, Mark Johnston wrote:
> On Mon, Nov 30, 2020 at 03:50:53PM +0200, Andriy Gapon wrote:
>> On 19/11/2020 16:57, Mark Johnston wrote:
>>> On Thu, Nov 19, 2020 at 01:28:56PM +0200, Andriy Gapon wrote:
>>>>
>>>> what do people think
On 19/11/2020 16:57, Mark Johnston wrote:
> On Thu, Nov 19, 2020 at 01:28:56PM +0200, Andriy Gapon wrote:
>>
>> what do people think about adding
>> setlocale(LC_NUMERIC, "");
>> to dtrace's main function?
>
> That seems reasonable to me.
>
&g
understanding of how this is supposed to actually work on FreeBSD is
> limited, though, so I defer...
Last time I checked mmap worked correctly with ZFS, that was before the switch.
Perhaps, there was an undetected issue -- this can be tested, e.g., by applying
the install chang
an environment DTRACE_LOCALE or whatever?
>
> Eh It's getting harder to live in the C locale anyway, the immigration rules
> seem to be tightening.
Sorry, but you don't have to use %'d.
You can keep using %d.
> On Thu, Nov 19, 2020 at 6:29 AM Andriy Gapon <mailto:a...@freebsd.or
what do people think about adding
setlocale(LC_NUMERIC, "");
to dtrace's main function?
My primary interest is to (pretty-)print some numbers with a thousands
separator.
Not sure if any other LC_ types are worth bothering.
--
An
On 07/11/2020 19:00, Mateusz Guzik wrote:
> Fixed as of r367454 (also see r367453).
Thank you!
> On 11/6/20, Mateusz Guzik wrote:
>> I think I have an idea how to keep this. In the meantime you can just
>> comment it out.
>>
>> On 11/6/20, Mateusz Guzik wrote
ession could be.
Perhaps something changed in the keyboard initialization?
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre
indeed I
suspect that the problem is with rms.
It looks like rms_rlock() does not change rmslock::readers, but rms_rowned()
checks it?
That's just from a first, super-quick look at the code.
> On 11/6/20, Andriy Gapon wrote:
>>
>> The subject panic happens for me with r36741
The subject panic happens for me with r367410 when mounting root filesystem.
The panic is in zfs_freebsd_cached_lookup -> zfs_lookup -> zfs_dirlook.
I have a picture of the screen with a little bit more details, I'll share it
later.
--
Andriy
ppened.
>
> So it seems that something has changed on zfsloader after 11.2 that brings
> this
> issue.
>
> My question is: Should it be expected or is it a bug to be fixed?
>
In my opinion it's a bug.
zfsloader should not require that
On 21/10/2020 15:20, Cassiano Peixoto wrote:
> Hi there,
>
> Anyone can help please? I've many servers with this same issue. Thanks
Can you try to replace /boot/zfsloader with zfsloader from other FreeBSD
versions?
E.g., 12.0, 12.2-RC, 11.4, recent snapshot of the CURRENT?
> On Fri, Oct 16,
u provide full CPU ID / features information from dmesg?
--
Andriy Gapon
___
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"
, then in Git for a long time and
> is just merged back into the Subversion repository. To put it
> bluntly, the people doing the work have voted with their feet years
> ago.
>
--
Andriy Gapon
___
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"
On 16/09/2020 10:05, Warner Losh wrote:
>
>
> On Wed, Sep 16, 2020 at 12:31 AM Andriy Gapon <mailto:a...@freebsd.org>> wrote:
>
> On 15/09/2020 23:13, Eirik Øverby wrote:
> > On 9/15/20 9:50 PM, Andriy Gapon wrote:
> >> On 15/09/2020 22:36, E
On 15/09/2020 23:13, Eirik Øverby wrote:
> On 9/15/20 9:50 PM, Andriy Gapon wrote:
>> On 15/09/2020 22:36, Eirik Øverby wrote:
>>> Now, since I updated from r365358 to r365688, I have not once been able to
>>> wake from sleep.
>>
>> Is that the only th
On 15/09/2020 22:36, Eirik Øverby wrote:
> Now, since I updated from r365358 to r365688, I have not once been able to
> wake from sleep.
Is that the only thing that changed?
Any port / package upgrades?
--
Andriy Gapon
___
freebsd-current@freeb
On 03/09/2020 10:01, Dave Cottlehuber wrote:
> On Thu, 3 Sep 2020, at 06:48, Andriy Gapon wrote:
>> On 03/09/2020 00:01, Navdeep Parhar wrote:
>>> Load cryptodev manually from the loader to boot and then add
>>> cryptodev_load="YES" to your loader.conf.
>&g
loader knows how to load dependencies.
--
Andriy Gapon
___
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"
serious bugs in its direct interface to
GEOM. We've seen all kinds of crashes with mfi at work.
Whatever the reason why mrsas is not always preferred over mfi, it must pretty
nebulous like POLA for existing users. From technical point of view, mrsas
appears to be superior
On 19/06/2020 17:14, Andriy Gapon wrote:
>
> If anyone interested in reviewing a new driver please help yourself to:
> https://reviews.freebsd.org/D25359
> https://reviews.freebsd.org/D25360
> What might be curious about it is that there are usb, i2c and gpio mixed
> toget
allout from /bin/sh?
>
> It's because kern.tty_info_kstacks is on by default now:
>
> https://svnweb.freebsd.org/changeset/base/362141
May I suggest that the stack trace is printed procstat -kk style (single line) ?
I think that the more compact output wo
If you get any problems with HDA sound driver, please be aware of r362294.
Please let me know about any problems that appear to be related to that commit.
It would be helpful to test if reverting the commit helps.
Thanks.
--
Andriy Gapon
___
freebsd
shell.
This way you will be using a compiler (toolchain, in general) form the
buildworld, not the currently installed compiler.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubsc
lout_stop_safe() at _callout_stop_safe+Bx82/frane Bxfe33c44aac
rsas_conplete_cnd() at mrsas_complete_cnd+8x1b8/frane BxfeB33c4daaed
ithread_loop() at ithread_loop+@x279/frame BxfeB33c44ah78
This looks like a fallout from r342064.
cm_callout is initialized like this:
callout_init_mtx(>cm
age as well and confuse their
callers.
--
Andriy Gapon
___
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"
On 27/05/2020 11:13, Andriy Gapon wrote:
> I added more diagnostics and it seems to support the idea that the problem is
> related to I/O cycles and bridges.
>
> ACPI timer suddenly starts returning 0x and that lasts for tens of
> microseconds before the timer goes ba
On 27/05/2020 01:14, John Baldwin wrote:
> On 5/26/20 11:55 AM, Konstantin Belousov wrote:
>> On Tue, May 26, 2020 at 06:22:13PM +0300, Andriy Gapon wrote:
>>> I am not sure if this is just a coincidence but it appears as if a write to
>>> some
>>> PCI conf
ed on the wrong queue.
>
> It is the management port, so I'm just using this hack for now:
>
> dev.igb.0.iflib.override_nrxqs=1
> dev.igb.0.iflib.override_ntxqs=1
This is a very common problem in our drivers.
E.g., https://reviews.freebsd.org/D24733
--
Andriy Gapon
___
On 25/05/2020 11:37, Andriy Gapon wrote:
> Also, there is another issue related to atrtc.
> When I have both drivers attached, and also when I have only atrtc attached
> (efi.rt.disabled=1), system clock jumps 10 minutes forward after each suspend
> /
> resume cycle (S0 -> S3
have both drivers attached, and also when I have only atrtc attached
(efi.rt.disabled=1), system clock jumps 10 minutes forward after each suspend /
resume cycle (S0 -> S3 -> S0). That does not happen for reboot and shutdown
cycles. I haven't investigated this deeper, but it is a curious prob
On 13/05/2020 17:42, Mark Johnston wrote:
> On Wed, May 13, 2020 at 10:45:24AM +0300, Andriy Gapon wrote:
>> On 13/05/2020 10:35, Andriy Gapon wrote:
>>> In r329363 I re-worked zfs_getpages and introduced range locking to it.
>>> At the time I believed that it was safe a
On 13/05/2020 10:35, Andriy Gapon wrote:
> On 13/05/2020 01:47, Bryan Drewery wrote:
>> Trivial repro:
>>
>> dd if=/dev/zero of=blah & tail -F blah
>> ^C
>> load: 0.21 cmd: tail 72381 [prev->lr_read_cv] 2.17r 0.00u 0.01s 0% 2600k
>>
5
>>> #5 vm_page_acquire_unlocked (object=0xf806cb637c60, pindex=1098,
>>> prev=, mp=0xfe2717fc6730, allocflags=21504) at
>>> /usr/src/sys/vm/vm_page.c:4469
>>> 4469if (!vm_page_grab_sle
Just to get a bigger exposure: https://reviews.freebsd.org/D24779
I think that this is a good idea and, if I am not mistaken, it should match the
Linux behavior.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org
On 09/05/2020 19:50, Konstantin Belousov wrote:
> On Sat, May 09, 2020 at 07:16:27PM +0300, Andriy Gapon wrote:
>> On 09/05/2020 19:13, Konstantin Belousov wrote:
>>> On Sat, May 09, 2020 at 06:52:24PM +0300, Andriy Gapon wrote:
>>>> I tried this change:
>>>
) at
/usr/devel/git/motil/sys/amd64/amd64/../../kern/subr_syscall.c:162
#47 amd64_syscall (td=0xfe009c7be800, traced=0) at
/usr/devel/git/motil/sys/amd64/amd64/trap.c:1161
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd
On 09/05/2020 19:50, Konstantin Belousov wrote:
> On Sat, May 09, 2020 at 07:16:27PM +0300, Andriy Gapon wrote:
>> On 09/05/2020 19:13, Konstantin Belousov wrote:
>>> On Sat, May 09, 2020 at 06:52:24PM +0300, Andriy Gapon wrote:
>>>> On 08/05/2020 19:15, Konstanti
On 09/05/2020 19:13, Konstantin Belousov wrote:
> On Sat, May 09, 2020 at 06:52:24PM +0300, Andriy Gapon wrote:
>> On 08/05/2020 19:15, Konstantin Belousov wrote:
>>> On Fri, May 08, 2020 at 06:53:24PM +0300, Andriy Gapon wrote:
>>>>
>>>> I have a repro
On 08/05/2020 19:15, Konstantin Belousov wrote:
> On Fri, May 08, 2020 at 06:53:24PM +0300, Andriy Gapon wrote:
>>
>> I have a reproducible panic with a custom kernel without option NUMA while
>> using
>> amdgpu driver from linuxkpi-based drm:
>>
>> p
IST_LOCK() is aware of such pages, but !NUMA one
is not.
--
Andriy Gapon
___
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"
1 - 100 of 1235 matches
Mail list logo
