a, rsp =
0x2f2048e41cf8, rbp = 0x2f2048e41d60 ---
KDB: enter: panic
[ thread pid 999 tid 100184 ]
Stopped at kdb_enter+0x33: movq $0,0x10538d2(%rip)
db>
--
Alexander Motin
), rip = 0x3fa386c2a8fa, rsp =
0x3fa379d24b38, rbp = 0x3fa379d24ba0 ---
Uptime: 28s
--
Alexander Motin
On 04.03.2024 15:33, Jakob Alvermark wrote:
On 3/4/24 21:13, Alexander Motin wrote:
On 04.03.2024 15:00, Poul-Henning Kamp wrote:
Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN
Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP
Nov 30 03:23:18 7950X3D-UFS
ld be good to
understand what's wrong is there exactly, since IMHO it is a big problem
now. Unfortunately HPS was unable to reproduce it on his laptop (that
makes me wonder if is is specific to chipset(s) or thunderbolt?), so it
ended nowhere so far.
--
Alexander Motin
John,
On 04.01.2024 09:20, John Kennedy wrote:
On Tue, Jan 02, 2024 at 08:02:04PM -0800, John Kennedy wrote:
On Tue, Jan 02, 2024 at 05:51:32PM -0500, Alexander Motin wrote:
On 01.01.2024 08:59, John Kennedy wrote:
...
My poudriere build did eventually fail as well
b.com/openzfs/zfs/pull/15732 .
--
Alexander Motin
On 14.11.2023 12:44, Alexander Motin wrote:
On 14.11.2023 12:39, Mateusz Guzik wrote:
One of the vnodes is probably not zfs, I suspect this will do it
(untested):
diff --git a/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c
b/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c
ange(invp, inoffp, outvp,
outoffp, lenp, flags, incred, outcred, fsize_td);
--
Alexander Motin
r, [x19, #768]
db>
I'll keep the debugger open for a while. Can I type something for
additional info?
Regards,
Ronald.
--
Alexander Motin
On 18.09.2023 19:21, Mark Millard wrote:
On Sep 18, 2023, at 15:51, Mark Millard wrote:
Alexander Motin wrote on
Date: Mon, 18 Sep 2023 13:26:56 UTC :
block_cloning feature is marked as READONLY_COMPAT. It should not
require any special handling from the boot code.
From stand/libsa/zfs
On 16. 9. 2023 19:14, Alexander Motin wrote:
On 16.09.2023 01:25, Graham Perrin wrote:
On 16/09/2023 01:28, Glen Barber wrote:
o A fix for the ZFS block_cloning feature has been implemented.
Thanks
I see
<https://github.com/openzfs/zfs/commit/5cc1876f14f90430b24f1ad2f231de936691940f>,
with
&
es
not even exist anywhere outside of FreeBSD base tree, I'd propose to
give this code another try here too. I see no point to have it disabled
at least in main unless somebody needs time to run some specific tests
first.
--
Alexander Motin
On 09.09.2023 12:32, Mark Millard wrote:
On Sep 8, 2023, at 21:54, Mark Millard wrote:
On Sep 8, 2023, at 18:19, Mark Millard wrote:
On Sep 8, 2023, at 17:03, Mark Millard wrote:
On Sep 8, 2023, at 15:30, Martin Matuska wrote:
On 9. 9. 2023 0:09, Alexander Motin wrote:
Thank you, Martin
as able to reproduce the issue with your script
and found the cause.
I first though the issue is triggered by the `cp`, but it appeared to be
triggered by `cat`. It also got copy_file_range() support, but later
than `cp`. That is probably why it slipped through testing. This patch
fixes it for me: https://github.com/openzfs/zfs/pull/15251 .
Mark, could you please try the patch?
--
Alexander Motin
the issue. I responded to the commit
email only because it makes no difference while vfs.zfs.bclone_enabled is 0.
That in turns means that someone may come up with some
other change for me to test by the time I get around to
setting up another test. Let me know if so.
--
Alexander Motin
On 04.09.2023 11:45, Mark Millard wrote:
On Sep 4, 2023, at 06:09, Alexander Motin wrote:
per_txg_dirty_frees_percent is directly related to the delete delays we see
here. You are forcing ZFS to commit transactions each 5% of dirty ARC limit,
which is 5% of 10% or memory size. I haven&#
On 04.09.2023 05:56, Mark Millard wrote:
On Sep 4, 2023, at 02:00, Mark Millard wrote:
On Sep 3, 2023, at 23:35, Mark Millard wrote:
On Sep 3, 2023, at 22:06, Alexander Motin wrote:
On 03.09.2023 22:54, Mark Millard wrote:
After that ^t produced the likes of:
load: 6.39 cmd: sh 4849 [tx
ge problems, like some huge delays, timeouts,
etc, that can be seen, for example, as busy percents regularly spiking
far above 100% in your `gstat -spod`.
--
Alexander Motin
Graham, the original SVG was scalable and searchable in browser. Your
PNG inside PDF is not.
--
Alexander Motin
#x27;t actually happening.
We wanted autotrim to be enabled by default, but it was not enabled, and
it was reported as not enabled, so there should be no confusion. The
only confusion may have been if you tried to read the code and see it
should have been enabled.
--
Alexander Motin
t affect any
already existing pools. On a new pool creation the default is now
officially "off", matching OpenZFS on other platforms, but there is no
reason why you can not set it to "on", if it is beneficial for your
devices and workloads. As alternative, for example, you may run trim
manually from time to time during any low activity periods.
--
Alexander Motin
)
On 22.08.2023 12:18, Alexander Motin wrote:
Hi Martin,
I am waiting for final test results from George Wilson and then will
request quick merge of both to zfs-2.2-release branch. Unfortunately
there are still not many reviewers for the PR, since the code is not
trivial, but at least with the
On 22.08.2023 14:24, Mark Millard wrote:
Alexander Motin wrote on
Date: Tue, 22 Aug 2023 16:18:12 UTC :
I am waiting for final test results from George Wilson and then will
request quick merge of both to zfs-2.2-release branch. Unfortunately
there are still not many reviewers for the PR
OpenZFS zfs-2.2-release branch (and of course later 15122)?
If the patches help I can cherry-pick them into main.
Alexander Motin wrote:
On 17.08.2023 15:41, Dag-Erling Smørgrav wrote:
Alexander Motin writes:
Trying to run your test (so far without reproduction) I see it
producing a
from
this specific deadlock. cd25b0f740 fixes some deadlocks in this area,
may be that is why you are getting issues less often, but I don't
believe it fixes this specific one, may be you was just lucky. Only
https://github.com/openzfs/zfs/pull/15122 I believe should fix them.
--
Alexander Motin
On 17.08.2023 15:41, Dag-Erling Smørgrav wrote:
Alexander Motin writes:
Trying to run your test (so far without reproduction) I see it
producing a substantial amount of ZIL writes. The range of commits
you reduced the scope to so far includes my ZIL locking refactoring,
where I know for sure
On 17.08.2023 14:57, Alexander Motin wrote:
On 15.08.2023 12:28, Dag-Erling Smørgrav wrote:
Mateusz Guzik writes:
Going through the list may or may not reveal other threads doing
something in the area and it very well may be they are deadlocked,
which then results in other processes hanging
. It would be good if you
could test it, though it seems to depend on few more earlier patches not
merged to FreeBSD yet.
--
Alexander Motin
redirection enabled on my systems, and I believe the
default there is also 115200, and even that is pretty slow. I see no
point to stay compatible if it is unusable.
--
Alexander Motin
fe023116a000
(kgdb) p dev->l2ad_hand
$2 = 225142071296
(kgdb) p dev->l2ad_evict
$3 = 225142063104
(kgdb) p *dev
value of type `l2arc_dev_t' requires 66136 bytes, which is more than
max-value-size
Never seen kgdb not being able to print a structure that reported to be too big.
--
Alexander Motin
ld be the
easiest test probably.
--
Alexander Motin
ion. I don't know what you are trying to achieve, but
as alternatives, the ZVOL can be passed inside VM, it can be shared via
iSCSI (even inside the host itself), etc.
--
Alexander Motin
ep
mode does not work on my system as well (even not S1).
Most important for the moment is that the system keeps running / is not
going down after x-time !
--
Alexander Motin
he traffic stops, what
happens if you run this command as root on the ugen which the if_ure
belongs to:
usbconfig -d ugenX.Y dump_string 0
Does the traffic resume?
Nope. Out of 4 times when traffic stopped 2 times it reported error> and 2 times it completed successfully, but it neither case it
recovered traffic. Only reset recovered it.
--
Alexander Motin
to 1 actually
help a lot more without so dramatic performance decrease. Though it is
likely only a workaround and does not explain the cause, so I hope Hans
more ideas for us to test. ;)
--
Alexander Motin
and since they have
different counters, it means that only few universal architectural
counters are usable, which are sufficient for basic profiling though.
There were some stability issues reported, but were solved by either
FreeBSD or BIOS update, so still not really diagnosed AFAIK.
--
Alexander Motin
On 17.06.2022 18:29, Larry Rosenman wrote:
On 06/17/2022 5:24 pm, Alexander Motin wrote:
On 17.06.2022 18:16, Larry Rosenman wrote:
On 06/17/2022 5:08 pm, Alexander Motin wrote:
On 17.06.2022 11:59, Larry Rosenman wrote:
I'm looking to upgrade the controllers in my TrueNAS box to
some
On 17.06.2022 18:24, Alexander Motin wrote:
On 17.06.2022 18:16, Larry Rosenman wrote:
On 06/17/2022 5:08 pm, Alexander Motin wrote:
On 17.06.2022 11:59, Larry Rosenman wrote:
I'm looking to upgrade the controllers in my TrueNAS box to
something that will
support 8TB drives be
On 17.06.2022 18:16, Larry Rosenman wrote:
On 06/17/2022 5:08 pm, Alexander Motin wrote:
On 17.06.2022 11:59, Larry Rosenman wrote:
I'm looking to upgrade the controllers in my TrueNAS box to something
that will
support 8TB drives because apparently my LSI 2108 controllers do not
suppor
ve certain (8TB) generation. We do not use Seagate
HDDs in our products, so about that instability I only heard from forums
and TrueNAS community user reports.
--
Alexander Motin
tps://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220604.png
--
Alexander Motin
be critical unless you either overheat them, or
somehow else they fail and wish to report it.
--
Alexander Motin
-write.
--
Alexander Motin
On 23.02.2022 22:01, Larry Rosenman wrote:
On 02/23/2022 8:58 pm, Alexander Motin wrote:
On 23.02.2022 21:52, Larry Rosenman wrote:
On 02/23/2022 8:41 pm, Alexander Motin wrote:
Hi Larry,
The panic you are getting is an assertion, enabled by kernel built
with INVARIANTS option. On 13 you
On 23.02.2022 21:52, Larry Rosenman wrote:
On 02/23/2022 8:41 pm, Alexander Motin wrote:
Hi Larry,
The panic you are getting is an assertion, enabled by kernel built
with INVARIANTS option. On 13 you may just not have that debugging
enabled to hit the issue. But that may be only a
at
https://www.lerctr.org/~ler/14-zfs-crash.png.
Booting from a 13-REL USB installer it imports and scrubs.
Ideas?
I can either video conference with shared screen or give access to the
console via my Dominion KVM.
Any help/ideas/etc welcome I really need to get this box back.
--
Alexander Motin
-L2 cache: 1280 kbytes, 8-way associative, 64 bytes/line
+L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line
--
Alexander Motin
even about “ancient” BIOS, the problem is, PXE stack does also need
resources and it is easier to consume low memory (just as loader does).
I've recently switched all my lab systems to UEFI PXE. It "just works"
for me using normal loader.efi of 872KB.
--
Alexander Motin
On 19.02.2022 13:23, Konstantin Belousov wrote:
On Sat, Feb 19, 2022 at 12:14:16PM -0500, Alexander Motin wrote:
On 19.02.2022 12:02, Mike Karels wrote:
On 18 Feb 2022, at 20:55, Tomoaki AOKI wrote:
Just a thought, but can it be the reason with timing (e.g., rendezvous
within (i)threads
case?
Or are they simply disable all Little cores and use big only?
Are there supported arm64 systems with asymmetric processors yet?
Mike
On Fri, 18 Feb 2022 15:36:27 -0500
Alexander Motin wrote:
This looks pretty weird to me, but I don't think it is specific to the
FA
;mailto:weike_c...@dell.com>
Internal Use - Confidential
--
Alexander Motin
devfs
* Optionally implementing d_fspacectl on other device types, like zvols.
This reminded me that we also have the same problem with DIOCGFLUSH.
Unlike regular files cache flush can be sent through devfs only with
ioctl(), not fsync()/fdatasync().
--
Alexander Motin
me thing: is it really needed to run so often and so accurate, or
may be we could reduce it to 1-2 times per second? Or may be it can be
avoided somehow 20 years later?
--
Alexander Motin
ut keep the lock pointer... The only way that
comes to mind is callout_init_mtx() in do_fork() if we assume the
process has completed and the struct proc was reused. I guess if we
could somehow leak scheduled callout in exit1(). May be we could add
some more assertions to try catch callout still being active there.
--
Alexander Motin
On 14.12.2021 22:00, Mark Millard wrote:
> On 2021-Dec-14, at 17:35, Alexander Motin wrote:
>
>> On 14.12.2021 20:21, Mark Millard wrote:
>>> I presume that because of FreeBSD's releng/13.0 and stable/13 (and
>>> releng/13.? futures) that:
>>>
&g
enzfs-2.0-linux:edonr
>>> /usr/share/zfs/compatibility.d/openzfs-2.1-linux:edonr
>>> /usr/share/zfs/compatibility.d/openzfsonosx-1.7.0:edonr
>>> /usr/share/zfs/compatibility.d/openzfsonosx-1.8.1:edonr
>>> /usr/share/zfs/compatibility.d/openzfsonosx-1.9.3:edonr
>>> /usr/share/zfs/compatibility.d/openzfsonosx-1.9.4:edonr
>>> /usr/share/zfs/compatibility.d/ubuntu-18.04:edonr
>>> /usr/share/zfs/compatibility.d/ubuntu-20.04:edonr
>>> /usr/share/zfs/compatibility.d/zol-0.7:edonr
>>> /usr/share/zfs/compatibility.d/zol-0.8:edonr
>>>
>>> I happened to do this activity in a aarch64 context, in
>>> case that matters.
>>
>>
>
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
>
--
Alexander Motin
> I happened to do this activity in a aarch64 context, in
> case that matters.
>
>
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
>
>
--
Alexander Motin
should fix the issue for the 64-bit machines,
which should be good enough for the most people.
--
Alexander Motin
57
> #11 0x807ca9eb in lapic_handle_timer (frame=0xfe0434de4f40)
> at /usr/src/sys/x86/x86/local_apic.c:1364
> #12
> #13 0x00080df42bb6 in ?? ()
> Backtrace stopped: Cannot access memory at address 0x7def2c90
> (kgdb)
>
>
>
--
Alexander Motin
see
>>>>>>>>> nvme0: Missing interrupt
>>>>>>>>> and now also
>>>>>>>>> Root mount waiting for: CAM
>>>>>>>>> messages besides those
>>>>>>>>>
>>>>>>>>
>>>>>>>> OK. That all makes sense. I'd forgotten that nvd_compat=1 by default
>>>>>>>> these
>>>>>>>> days.
>>>>>>>>
>>>>>>>> I'll take a look on monday starting at the differences in interrupt
>>>>>>>> assignment that
>>>>>>>> are apparent when you cold boot vs reboot.
>>>>>>>>
>>>>>>>> Thanks for checking... I'd hoped this was a cheap fix, but also
>>>>>>>> didn't really
>>>>>>>> expect it to be.
>>>>>>>>
>>>>>>>> Warner
>>>>>>>>
>>>>>>>>
>>>>>>> I've recently upgraded to main-n249974-17f790f49f5 and it got even
>>>>>>> worse now.
>>>>>>> So clean poweron works as before.
>>>>>>> But if rebooted nvme drive refuses to work, while before the code
>>>>>>> upgrade it was just complaining about missing interrupts.
>>>>>>>
>>>>>>> currently dmesg show this:
>>>>>>> nvme0: mem
>>>>>>> 0xcc10-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at
>>>>>>> device
>>>>>>> 0.0 on pci6
>>>>>>> nvd0: NVMe namespace
>>>>>>> nvd0: 488386MB (1000215216 512 byte sectors)
>>>>>>> nvme0: mem
>>>>>>> 0xcc10-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at
>>>>>>> device
>>>>>>> 0.0 on pci6
>>>>>>>
>>>>>>
>>>>>> Why is this showing up twice? Or is everything above this line left
>>>>>> over from the first, working boot?
>>>>>>
>>>>>>
>>>>>>> nvme0: RECOVERY_START 9585870784 vs 9367036288
>>>>>>> nvme0: timeout with nothing complete, resetting
>>>>>>> nvme0: Resetting controller due to a timeout.
>>>>>>> nvme0: RECOVERY_WAITING
>>>>>>> nvme0: resetting controller
>>>>>>> nvme0: aborting outstanding admin command
>>>>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:0001
>>>>>>> cdw11:
>>>>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0
>>>>>>> nvme0: nvme_identify_controller failed!
>>>>>>> nvme0: waiting
>>>>>>>
>>>>>>
>>>>>> Clearly something bad is going on with the drive here... We looked
>>>>>> into the completion queues when we didn't get an interrupt and there was
>>>>>> nothing complete there
>>>>>>
>>>>>> The only thing I can think of is that this means there's a phase error
>>>>>> between the drive and the system. I recently removed a second reset and
>>>>>> made it an option NVME_2X_RESET. Can you see if adding
>>>>>> 'options NVME_2X_RESET' to your kernel config fixes this?
>>>>>>
>>>>>> Warner
>>>>>>
>>>>>>
>>>>>>> nvme0: mem
>>>>>>> 0xcc10-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at
>>>>>>> device
>>>>>>> 0.0 on pci6
>>>>>>> nvme0: RECOVERY_START 9362778467 vs 9361830561
>>>>>>> nvme0: timeout with nothing complete, resetting
>>>>>>> nvme0: Resetting controller due to a timeout.
>>>>>>> nvme0: RECOVERY_WAITING
>>>>>>> nvme0: resetting controller
>>>>>>> nvme0: aborting outstanding admin command
>>>>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:0001
>>>>>>> cdw11:
>>>>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0
>>>>>>> nvme0: nvme_identify_controller failed!
>>>>>>> nvme0: waiting
>>>>>>>
>>>>>>>
>>>>>
>>>>> Sorry, it's showing twice due to multiple reboots. For one boot it's
>>>>> like:
>>>>> nvme0: mem
>>>>> 0xcc10-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at
>>>>> device
>>>>> 0.0 on pci6
>>>>> nvme0: RECOVERY_START 9633303481 vs 9365971423
>>>>> nvme0: timeout with nothing complete, resetting
>>>>> nvme0: Resetting controller due to a timeout.
>>>>> nvme0: RECOVERY_WAITING
>>>>> nvme0: resetting controller
>>>>> nvme0: aborting outstanding admin command
>>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:0001 cdw11:
>>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0
>>>>> nvme0: nvme_identify_controller failed!
>>>>> nvme0: waiting
>>>>>
>>>>> Well, neither Windows not Linux have any problems with the device. I
>>>>> understand they may be hiding it or workaround somehow.
>>>>>
>>>>
>>>> Yea, I'm trying to figure out why your machine is different than mine,
>>>> and what Windows or Linux do that is different. It may be dodgy hardware,
>>>> but others have no trouble...
>>>>
>>>> I'll try setting NVME_2X_RESET in the kernel config and report back in a
>>>>> while.
>>>>>
>>>>
>>>> Thanks. If it helps, that tells me something. If it doesn't, that tells
>>>> me something else.
>>>>
>>>> I suspect that it is somewhere else in the system, tbh, but I need to
>>>> find it systematically.
>>>>
>>>> Warner
>>>>
>>>
>>> Surprisingly, setting NVME_2X_RESET in the kernel config hasn't changed
>>> anything. I. e it didn't help.
>>>
>>
>> While it would have been nice to have this be the fix, I'm not that
>> surprised either.
>> It was the biggest change of late, apart from the big re-arrangement that
>> I'd done.
>>
>> So the other changes have moved from the occasional missing interrupt
>> message
>> (which the old code would get when a command wasn't completed in the
>> timeout
>> period, but that we found to be done when we scanned the completion queue.
>> Now
>> the device is detected fine (as before), but then doesn't do I/O at all
>> (including not
>> completing the identify command!) and is worse. This is unexpected and I'm
>> trying
>> understand what happens on reboot that 'changes'the working state and why
>> the
>> new code behaves so differently.
>>
>> Warner
>>
>
--
Alexander Motin
ch/079237.html
>>
>> [2]
>> https://lists.freebsd.org/pipermail/freebsd-current/2021-March/079240.html
>>
>> [3]
>> https://lists.freebsd.org/pipermail/dev-commits-src-main/2021-September/007513.html
>>
>> [4]
>> https://lists.freebsd.org/pipermail/dev-commits-src-main/2021-September/007512.html
>>
>> --
>> Tomoaki AOKI
--
Alexander Motin
On 05.10.2020 17:39, Alexander Motin wrote:
> On 05.10.2020 17:20, Warner Losh wrote:
>> On Mon, Oct 5, 2020 at 12:36 PM Alexander Motin > <mailto:m...@freebsd.org>> wrote:
>>
>> I can add that we've received report about identical panic on FreeBSD
>
On 05.10.2020 17:20, Warner Losh wrote:
> On Mon, Oct 5, 2020 at 12:36 PM Alexander Motin <mailto:m...@freebsd.org>> wrote:
>
> I can add that we've received report about identical panic on FreeBSD
> releng/12.2 of r365436, AKA TrueNAS 12.0-RC1:
> http
only head.
--
Alexander Motin
___
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"
after booting to be recognized.
I don't know what is the problem here, but I guess that
vfs.root_mount_always_wait may help here too, if we assume that the
problem is that some app is trying to open the serial adapter before the
USB scan is complete, that previously was workarounded by delay ca
On 06.12.2019 21:08, Steve Kargl wrote:
> On Fri, Dec 06, 2019 at 07:09:55PM -0500, Alexander Motin wrote:
>> On 06.12.2019 18:41, Steve Kargl wrote:
>>> On Fri, Dec 06, 2019 at 06:15:32PM -0500, Alexander Motin wrote:
>>>> On 06.12.2019 17:52, Steve Kargl wrote:
&g
On 06.12.2019 18:41, Steve Kargl wrote:
> On Fri, Dec 06, 2019 at 06:15:32PM -0500, Alexander Motin wrote:
>> On 06.12.2019 17:52, Steve Kargl wrote:
>>> On Fri, Dec 06, 2019 at 03:33:09PM -0700, Warner Losh wrote:
>>>> On Fri, Dec 6, 2019 at 3:31 PM Steve Karg
tors)
> da0: quirks=0x2
>
> plugged into the port.
If system hangs even without any USB disk attached, then I don't see a
relation between CAM and USB here. My change could affect some timings
of the boot process, but without closer debugging it is hard to guess
something. To be sure whether USB is related I would try to disable all
USB controllers either in BIOS or with set of loader tunables like
hint.ehci.0.disabled=1 , hint.ohci.0.disabled=1 ,
hint.xhci.0.disabled=1, ...
--
Alexander Motin
___
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"
the failing kernel is r 355452
> >
>
> The problem seems to be caused 355010. This is a commit to
> fix CAM, which seems to break USB.
>
> Yes. mav@ made this change...
Yes, I made the change, and it was supposed to improve USB
inter-operation, but
src tree and after rebuilding the kernel SES started to
> work as expected. I don’t want to run CURRENT just for this simple fix.
--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-cur
y for the
> machine may be found at
> http://www.catwhisker.org/~david/FreeBSD/history/freebeast.13_dmesg.txt
>
> I'm about to find out if my laptop (which shares the above salient
> characteristics, and is being updated in parallel) exhibits similar
> symptoms.
>
> Peac
ot;ok".
Thank you for the report. r351589 should fix it.
--
Alexander Motin
___
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 dmesg, error messages, etc. On my
test systems I see no problems.
--
Alexander Motin
___
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"
h this
patch on very quick tests card seems working properly.
On 08.11.2016 07:42, Alexander Motin wrote:
> As I have told before, this card is from completely different price
> segment then proper SAS/SATA HBAs. For its $80 it is not promised to be
> reliable. But in case anything can be
aniel Engberg wrote:
> I discussed this card briefly with Alexander Motin (@mav) back in 2015,
> https://forums.freebsd.org/threads/50411/page-2#post-282648 .
> I've CCed him for suggestions.
>
> https://lists.freebsd.org/pipermail/freebsd-current/2016-October/063668.
> Can anybody test of output for:
>>>>
>>>> zfs list
>>>>
>>>> command on FreeBSD current after r305211 ? On my hosts his leads to
>>>> zfs segfault.
>>
>> --
>> Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@ya
Hi.
On 03.09.2016 23:50, Subbsd wrote:
> Can anybody test of output for:
>
> zfs list
>
> command on FreeBSD current after r305211 ? On my hosts his leads to
> zfs segfault.
Works normally for me at r305342. Any more information?
-
ght solution, but suppose that in couple years nobody
will bother about that hardware at all.
--
Alexander Motin
___
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"
issue is gone.
>
> Reverted commits: r296510, r296512, r296514, r296516, r296519,
> r296521, r296523, r296528, r296530
Should be fixed by r296563.
Illumos assumes full sync between kernel and world, so they are quietly
breaking ABI as often as they want for any new feature. O
will just remain frozen forever, that will be
will be difficult to diagnose, but I would better just dropped device
freeze in that case same as in case of completion with error.
--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
On 26.05.2015 09:06, Neel Natu wrote:
> On Mon, May 25, 2015 at 1:40 PM, Garrett Cooper wrote:
>> On Apr 28, 2015, at 0:54, Alexander Motin wrote:
>>> On 27.04.2015 21:17, Garrett Cooper wrote:
>>>> On Apr 27, 2015, at 11:16, Garrett Cooper
>>>> wrot
ny other load on host except this VM
that could cause I/O delays high enough to trigger timeouts? What are
you using to back the virtual disk (file, zvol, ...)?
--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd
Hi.
> I've got the following panic running FreeBSD-11-current:
I'm sorry, it was my mistake. Should be fixed by r281310.
Though that is generally a bad Carma to loose active swap device.
--
Alexander Motin
___
freebsd-current@freebs
bers are mostly informational, since any real performance
investigation would require a histogram rather the a single average
number.
--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
AL(inq_data) &
>> 0x08) != 0)
>> +#define SID_QUAL_IS_VENDOR_UNIQUE(inq_data) ((SID_QUAL(inq_data) &
>> 0x04) != 0)
>>u_int8_t dev_qual2;
>> #define SID_QUAL2 0x7F
>> #define SID_LU_CONG0x40
>
> CCin
which suggests all references were
> closed) instead of waiting.
>
> Adding mav@ as he may have some idea.
Some time ago I experimented with ZFS behavior in situation of
disappearing disks. I fixed several most easily reproducible
scenarios, but finally I've got to conclusion that ZFS in
On 20.04.2014 22:51, Andrey Fesenko wrote:
On Sun, Apr 20, 2014 at 11:44 PM, Alexander Motin wrote:
On 20.04.2014 22:31, Andrey Fesenko wrote:
On Thu, Apr 17, 2014 at 2:10 PM, Andrey Fesenko
wrote:
if disconnect ssd
pr 17 14:07:08 desktop kernel: ahcich3: DISCONNECT requested
Apr 17 14:07
freely. The limitations could be
read/set with `camcontrol negotiate pass2 -U`, and affect operation
after following `camcontrol reset ...`.
--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd
On 19.02.2014 23:44, Slawa Olhovchenkov wrote:
On Wed, Feb 19, 2014 at 11:04:49PM +0200, Alexander Motin wrote:
On 19.02.2014 22:04, Adrian Chadd wrote:
On 19 February 2014 11:59, Alexander Motin wrote:
So if we're moving towards supporting (among others) a pcbgroup / RSS
hash style
On 19.02.2014 22:04, Adrian Chadd wrote:
On 19 February 2014 11:59, Alexander Motin wrote:
So if we're moving towards supporting (among others) a pcbgroup / RSS
hash style work load distribution across CPUs to minimise
per-connection lock contention, we really don't want the sc
On 19.02.2014 21:51, Adrian Chadd wrote:
On 19 February 2014 11:40, Alexander Motin wrote:
Clock interrupt threads, same as other ones are only softly bound to
specific CPUs by scheduler preferring to run them on CPUs where they are
scheduled. So far that was enough to balance load, but
Hi.
Clock interrupt threads, same as other ones are only softly bound to
specific CPUs by scheduler preferring to run them on CPUs where they are
scheduled. So far that was enough to balance load, but allowed threads
to migrate, if needed. Is it too flexible for some use case?
--
Alexander
ROM, SIP_MEDIA_REMOVABLE, "CHINON", "CD-ROM
CDS-535","*"},
/* quirks */ CD_Q_BCD_TRACKS
+ },
+ {
+ { T_CDROM, SIP_MEDIA_REMOVABLE, "SAMSUNG", "CD-ROM","1.00"},
+ /* quirks */ CD_Q_NO_CHA
n_internal
This should return a line w/ a large hex number at the front, then run:
addr2line -e /boot/kernel/kernel $( expr 0x+0x9c9)
This will give you a file name and line number, and can you copy/paste
the lines around and including that line number? This w
e is no callout lock. I am not sure whether we should better add
check or assertion to _callout_init_lock().
So either VT passes something odd/NULL pointer to callout_init_mtx(), or
something overwrites the callout structure after scheduling the callout.
--
Alexander Motin
___
On 18.11.2013 21:11, Jeff Roberson wrote:
On Mon, 18 Nov 2013, Alexander Motin wrote:
I've created patch, based on earlier work of avg@, to add back
pressure to UMA allocation caches. The problem of physical memory or
KVA exhaustion existed there for many years and it is quite critical
no
On 18.11.2013 14:10, Adrian Chadd wrote:
On 18 November 2013 01:20, Alexander Motin wrote:
On 18.11.2013 10:41, Adrian Chadd wrote:
So, do you get any benefits from just the first one, or first two?
I don't see much reason to handle that in pieces. As I have described above,
each par
On 18.11.2013 11:45, Luigi Rizzo wrote:
On Mon, Nov 18, 2013 at 10:20 AM, Alexander Motin mailto:m...@freebsd.org>> wrote:
On 18.11.2013 10:41, Adrian Chadd wrote:
Your patch does three things:
* adds a couple new buckets;
These new buckets make bucket siz
So, do you get any benefits from just the first one, or first two?
I don't see much reason to handle that in pieces. As I have described
above, each part has own goal, but they much better work together.
On 17 November 2013 15:09, Alexander Motin wrote:
Hi.
I've created
ve in viability of this approach for longer runs.
I would like to hear some comments about that:
http://people.freebsd.org/~mav/uma_pressure.patch
Thank you.
--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/m
1 - 100 of 481 matches
Mail list logo
