Re: nullfs and ZFS issues

[Eirik Øverby]

On Mon, 2022-04-25 at 15:27 +0200, Alexander Leidinger wrote:
> Quoting Alexander Leidinger  (from Sun, 24  
> Apr 2022 19:58:17 +0200):
> 
> > Quoting Alexander Leidinger  (from Fri, 22  
> > Apr 2022 09:04:39 +0200):
> > 
> > > Quoting Doug Ambrisko  (from Thu, 21 Apr  
> > > 2022 09:38:35 -0700):
> > 
> > > > I've attached mount.patch that when doing mount -v should
> > > > show the vnode usage per filesystem.  Note that the problem I was
> > > > running into was after some operations arc_prune and arc_evict would
> > > > consume 100% of 2 cores and make ZFS really slow.  If you are not
> > > > running into that issue then nocache etc. shouldn't be needed.
> > > 
> > > I don't run into this issue, but I have a huge perf difference when  
> > > using nocache in the nightly periodic runs. 4h instead of 12-24h  
> > > (22 jails on this system).
> > > 
> > > > On my laptop I set ARC to 1G since I don't use swap and in the past
> > > > ARC would consume to much memory and things would die.  When the
> > > > nullfs holds a bunch of vnodes then ZFS couldn't release them.
> > > > 
> > > > FYI, on my laptop with nocache and limited vnodes I haven't run
> > > > into this problem.  I haven't tried the patch to let ZFS free
> > > > it's and nullfs vnodes on my laptop.  I have only tried it via
> > > 
> > > I have this patch and your mount patch installed now, without  
> > > nocache and reduced arc reclaim settings (100, 1). I will check the  
> > > runtime for the next 2 days.
> > 
> > 9-10h runtime with the above settings (compared to 4h with nocache  
> > and 12-24h without any patch and without nocache).
> > I changed the sysctls back to the defaults and will see in the next  
> > run (in 7h) what the result is with just the patches.
> 
> And again 9-10h runtime (I've seen a lot of the find processes in the  
> periodic daily run of those 22 jails in the state "*vnode"). Seems  
> nocache gives the best perf for me in this case.

Sorry for jumping in here - I've got a couple of questions:
- Will this also apply to nullfs read-only mounts? Or is it only in
case of writing "through" a nullfs mount that these problems are seen?
- Is it a problem also in 13, or is this "new" in -CURRENT?

We're having weird and unexplained CPU spikes on several systems, even
after tuning geli to not use gazillions of threads. So far our
suspicion has been ZFS snapshot cleanups but this is an interesting
contender - unless the whole "read only" part makes it moot.

/Eirik

Re: Deprecating ISA sound cards

[Eirik Øverby]

On Sat, 2022-03-19 at 02:24 +, Mark Linimon wrote:
> Anyone objecting to this, be careful, I might ship a pile of such
> things to you from the depths of the closets :-)

Such threats! :>
But I've already volunteered as tribute here. I won't be arguing hard
for keeping these drivers (seeing as I'm clearly the oddball for having
FreeBSD running on hardware which has 1) ISA bus and 2) ISA sound
cards..), but I'll be willing to suffer any pile of cards that would
otherwise land on the trash heap..

/Eirik

Re: zfskeys does not exist

[Eirik Øverby]

On Sun, 2021-11-14 at 00:10 +0900, Tomoaki AOKI wrote:
> On Sat, 13 Nov 2021 13:00:59 +0100
> Gary Jennejohn  wrote:
> 
> > On Sat, 13 Nov 2021 11:33:01 +
> > Graham Perrin  wrote:
> > 
> > > 
> > >  (2021-07-28):
> > > 
> > >  > Add zfskeys rc.d script for auto-loading encryption keys  
> > > 
> > >  finds only the July 
> > > commit.
> > > 
> > > Below, I don't have zfskeys. Please, can anyone explain?
> > > 
> > > Thanks
> > > 
> > 
> > /usr/src/libexec/rc/rc.d/zfskeys
> > 
> > Maybe it isn't being installed automatically?  No idea and I don't
> > use ZFS myself.
> 
> (CC'ing Allan Jude, the committer of this change.)
> 
> If these are intentionally kept unchanged, there can be some risk to
> install zfskeys in some situations.

As the author of zfskeys, I cannot imagine what damage it could
possible do, and I fully expect(ed) it to be installed by default. It
has to be explicitly enabled in rc.conf(.*); it's a noop otherwise.

/Eirik

Re: Wake from sleep kinda broken-ish? (ThinkPad Carbon X1 6th gen)

[Eirik Øverby]

On Wednesday, September 16, 2020 9:05:43 AM CEST Warner Losh wrote:
> I too can report this for my Lenovo Yoga running code as of September 13,
> but with manu's latest drm...  It used to work fine, but my last build on
> the system was from May. Most likely a new panic in that code path, but
> I've not chased down further...

So I got a gen8 to play with, and the list of grievances is long - but I have 
one observation that may be of interest:
The gen8 would be usable (at least seemingly so) with a 13-kernel from lat 
2019 or very early 2020. Then around the end of January - I've bisected it 
down to around Jan 24, give or take, it would start wedging _hard_ after a 
minute or two of heavy load (compiling, cat /dev/random, that sort of thing). 
It was a problem prior to that too but it was _much_ harder to trigger, at 
least based on my tests this weekend.

The "solution" is to add
  hint.hwpstate_intel.0.disabled="1"
to /boot/loader.conf. This obviously has disastrous impact on battery life. 
The emt module takes over, so power management is a lot more rudimentary 
(powerd now does nearly nothing, while powerd++ kills interactivity). Battery 
life is much shorter than on my gen6, and it gets hotter.

BUT: This thing - gen8 - would get stuck in the acpi_beep before adding this 
to loader.conf. After adding the hint, I have not had a single failure when 
resuming. It's behaving much better than my gen6.

Worth noting that I patched the ig4 driver to allow it to find the I2C device 
(just adding the PCI device IDs to the end of the lists already there), so 
iichid would work and give me a trackpad. Latest drm-devel-kmod works well, 
but install the xf86 intel driver and set "AccelMethod" "sna" in the 
appropriate xorg config file.

/Eirik


___
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: Wake from sleep kinda broken-ish? (ThinkPad Carbon X1 6th gen)

[Eirik Øverby]

On 9/16/20 11:05 AM, Hans Petter Selasky wrote:


To make sure suspend/resume is not blocked by USB you can try setting:

sysctl hw.usb.no_suspend_wait=1


Thanks, that is useful - it's a separate problem with my USB DAC. Not sure if 
it's relevant to the resume issue, though?

/Eirik
___
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: Wake from sleep kinda broken-ish? (ThinkPad Carbon X1 6th gen)

[Eirik Øverby]

On 9/16/20 9:07 AM, Li-Wen Hsu wrote:
> On Wed, Sep 16, 2020 at 2:30 PM Andriy Gapon  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, 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?
>>>
>>> There have been updates to packages, yes - but it didn't even occur to me 
>>> that these could impact the resume process at such an early stage. Not sure 
>>> which that would be; obviously the drm module has been rebuilt each time I 
>>> upgraded, but I don't have any other kernel modules installed from packages.
> 
> Which version of drm module are you using?

13.0-CURRENT FreeBSD 13.0-CURRENT #7 r365688
drm-devel-kmod-5.4.62.g20200905_1

Built against the running kernel sources, of course.


>> Yes, I specifically had drm modules in mind.
> 
> I also use X1C 6th and it was working perfectly after updating BIOS to
> 1.30 (which I'm currently using) in Sep. 2018 [1]. I don't remember
> any suspend/resume failures. But since late 2019, it has exactly the
> same symptom as yours. Suspending is fine, but upon resuming, there is
> about a 50% probability that the power LDE continues pulsating with
> all other LDEs like FnLock and CapsLock are on like the machine is
> awake.

Right-o.

/Eirik
___
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: Wake from sleep kinda broken-ish? (ThinkPad Carbon X1 6th gen)

[Eirik Øverby]

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 thing that changed?
> Any port / package upgrades?

There have been updates to packages, yes - but it didn't even occur to me that 
these could impact the resume process at such an early stage. Not sure which 
that would be; obviously the drm module has been rebuilt each time I upgraded, 
but I don't have any other kernel modules installed from packages.

/Eirik
___
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"

Wake from sleep kinda broken-ish? (ThinkPad Carbon X1 6th gen)

[Eirik Øverby]

Hi,

ever since I started using my 6th gen ThinkPad X1 Carbon as my daily work horse 
back in 2019 I have had occasional problems getting it to wake from sleep. 
Lately I thought I had nailed it down somewhat - making sure I close the lid 
(which is the only condition in which it will sleep on its own) only while the 
screen is actually on. Closing the lid when the screensaver had turned the 
display off would almost certainly prevent waking from sleep.

Now, since I updated from r365358 to r365688, I have not once been able to wake 
from sleep.

The problem manifests thus: The computer seems to go to sleep correctly; the 
LED on the display starts pulsating as it should and all fan activity stops. 
Upon opening the lid, the pulsating stops, but the power LED pulsates instead. 
There is no display activity and no signs of it actually waking up. 
Force-power-off is the only way to resuscitate, after which (and I am fairly 
sure I'm not imagining this) it is very hard to get my GELI password right - so 
another power cycle is required before the keyboard is fully reliable pre-boot.

I have absolutely no idea how to go about debugging this. The BIOS on the 
system is pretty new, the TPM chip is disabled (that seemed to help reliability 
quite a bit), and unused/unsupported devices are disabled in BIOS. No BIOS 
configuration has changed between the revisions.

Any hints would be more than welcome.

Thanks all,
/Eirik
___
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: DRM-current-kmod is still a problem at r353339

[Eirik Øverby]

On 10/17/19 11:29 PM, Eirik Øverby wrote:
> On 10/17/19 10:31 PM, Niclas Zeising wrote:
>> On 2019-10-17 21:53, ma...@freebsd.org wrote:
>>> On Thu, Oct 17, 2019 at 03:03:51PM +0200, Niclas Zeising wrote:
..
>>> I believe it was the recent work on the vm page busy state, r353539
>>> specifically.  This patch should fix it; we don't yet have a
>>> __FreeBSD_version number bump on which to gate the patch.
...>>
>> Hi!
>> Hopefully someone can confirm that this patch to drm-current-kmod or 
>> drm-devel-kmod fixes the issue.  I won't be able to work on this before the 
>> weekend at the earliest, I'm afraid.
>> Mark, is it possible to get a belated version bump for this fix, and what 
>> changed to require it?
> 
> Built, rebooting ... Will hopefully check back in soon.

And tada, I'm back. That seemed to do the trick. Thanks!

/Eirik
___
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: DRM-current-kmod is still a problem at r353339

[Eirik Øverby]

On 10/17/19 10:31 PM, Niclas Zeising wrote:
> On 2019-10-17 21:53, ma...@freebsd.org wrote:
>> On Thu, Oct 17, 2019 at 03:03:51PM +0200, Niclas Zeising wrote:
>>> On 2019-10-16 18:57, Neel Chauhan wrote:
 While drm-current-kmod worked for a little while, it broke with r353645.

 https://i.imgur.com/Q5nYZf2.jpg

 I'm using the same HP Spectre that I used earlier (where it worked and
 where it panicked).

>>>
>>> That commit looks unrelated, it touches the wbwd and superio drivers,
>>> nothing else.  Any chance you can bisect exactly which revision that
>>> caused the new issues?
>>
>> I believe it was the recent work on the vm page busy state, r353539
>> specifically.  This patch should fix it; we don't yet have a
>> __FreeBSD_version number bump on which to gate the patch.
>>
>> diff --git a/linuxkpi/gplv2/src/linux_page.c 
>> b/linuxkpi/gplv2/src/linux_page.c
>> index e2b85c45c..060ae85ed 100644
>> --- a/linuxkpi/gplv2/src/linux_page.c
>> +++ b/linuxkpi/gplv2/src/linux_page.c
>> @@ -239,7 +239,7 @@ retry:
>>   page = vm_page_lookup(devobj, i);
>>   if (page == NULL)
>>   continue;
>> -    if (vm_page_sleep_if_busy(page, "linuxkpi"))
>> +    if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL))
>>   goto retry;
>>   cdev_pager_free_page(devobj, page);
>>   }
> 
> Hi!
> Hopefully someone can confirm that this patch to drm-current-kmod or 
> drm-devel-kmod fixes the issue.  I won't be able to work on this before the 
> weekend at the earliest, I'm afraid.
> Mark, is it possible to get a belated version bump for this fix, and what 
> changed to require it?

Built, rebooting ... Will hopefully check back in soon.

/Eirik
___
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: DRM-current-kmod is still a problem at r353339

[Eirik Øverby]

On 10/17/19 3:03 PM, Niclas Zeising wrote:> On 2019-10-16 18:57, Neel Chauhan 
wrote:
>> While drm-current-kmod worked for a little while, it broke with r353645.
>>
>> https://i.imgur.com/Q5nYZf2.jpg
>>
>> I'm using the same HP Spectre that I used earlier (where it worked and where 
>> it panicked).
>>
> 
> That commit looks unrelated, it touches the wbwd and superio drivers, nothing 
> else.  Any chance you can bisect exactly which revision that caused the new 
> issues?

I have the same problem, same panic, as Neel. ThinkPad X1 Carbon Gen6.

I'm bulding again right now, but my previous build was from EuroBSDCon so 
finding the commit that breaks is going to be kinda hard (unless you have some 
ninja trick to teach me). I notice there has been some significant changes to 
vm_pmap.c and friends since my build from yesterday, so here's hoping it's 
fixed..

Wbr
/Eirik
___
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: ZFS Stability MySQL (Comments Requested)

[Eirik Øverby]

Hi,

just chirping in; we've upgraded a bunch of old 6.x servers to 8.0 with ZFS. 
This is a pair of HP DL385 G1s (dual opteron, old stuff) with SmartArray 
controllers, which had absolutely horrible performance in both 6.0 and 8.0. The 
drive array gave us ~25 mbyte/s sustained, which is obviously abysmal for 
U320/15k SCSI drives backed by hardware RAID and cache.

We ended up splitting the hardware RAID into single drives, and using 
ZFS/RaidZ. We suddenly got around 45 mbye/s (still bad) per channel, adding up 
nicely when benchmarking the RaidZ volume.

MySQL now performs much better than before, and we've enabled compression 
(gzip-2) and fixed block sizes. Compression ratio is about 1.7:1, transaction 
latency on the database (as seen from application) has gone down by about 65% 
on average.

We see anything between 300 and 2000 queries/second throughout the day, and our 
active dataset is about 500GB. The servers have 8GB of memory.

/Eirik

On Apr 29, 2010, at 4:31 PM, Jason J. W. Williams wrote:

 Hi Y'all,
 
 I've written before that we're considering moving to FreeBSD 8 from
 OpenSolaris and are heavily reliant on ZFS. Has anyone used FreeBSDs
 ZFS implementation for a high reliability environment like a database?
 If so, what are your experiences?
 
 Basically, I'm curious how stable the implementation is and whether
 it's ready for a critical production environment. Also, any gotchas
 particularly with running it with MySQL or anything else that utilizes
 a lot of memory. On Solaris, we cap the max ARC size to keep it from
 grabbing all the system RAM and competing with MySQL.
 
 Any thoughts or comments are greatly appreciated.
 
 -J
 ___
 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
 

___
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