- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Yesterday
Fri, Jun 20
Here is an example of how I made use of this code in iichid when it still was out-of-tree:
https://github.com/avg-I/iichid/commit/d5c33b243c599fd234685a2cd8ee1bd1fb67e1b0
May 20 2025
May 19 2025
May 14 2025
In D50338#1148850, @olce wrote:In D50338#1148702, @avg wrote:I pointed out this problem to Kirk and Colin back when the change was made.
I had to do the same kind of fix locally (for Panzura) because of live-locks as well.I should probably have contacted you when I saw the revert commit, as even if I hadn't suspected there was a problem with it and hadn't experienced deadlocks yet, I was interested in the vnode cache and had analyzed quite a bunch of it at that time already.
That said, it would have been nice that Kirk and Colin put the revert under review (I suspect they didn't in part because they were running out of time) so that your "objection" could be logged. Were there any specific problems preventing you from submitting your local fix, or just lack of time?
Anyway, we are now at risk of shipping 14.3 with this annoying bug (although I don't know its frequency in general; all I can say is that, for my use case, it's becoming super annoying). I hope the fix here will be included in 14.3. Will normally have finished my tests in a couple of hours (now with the reload of numvnodes), and will report here.
Thank you very much!
I pointed out this problem to Kirk and Colin back when the change was made.
I had to do the same kind of fix locally (for Panzura) because of live-locks as well.
But I have one small difference, not sure if important, which I'll describe in an inline comment.
Apr 18 2025
Thank you!
Mar 7 2025
Looks good to me.
Feb 21 2025
Feb 7 2025
Still looks good to me.
Feb 6 2025
Feb 5 2025
The change looks good to me.
Thank you.
Jan 14 2025
I think that vmxnet3_isc_txd_credits_update can be made similar to, e.g., igb_isc_txd_credits_update with respect to the array index (tx_rs_cidx and vxcr_next respectively).
That is, we can stash vxcr_next into a local variable and then use the local variable for iteration.
At the end, we can update vxcr_next from the local variable.
This won't fix other potential issues with correctness / concurrency (data races), but at least it will ensure that vxcr_next will not have an out-of-bounds value.
Jan 10 2025
@jhb my personal / private interest in sleepable ithreads is "natural" support for interrupt controllers on slow buses.
Originally, it was assumed that an interrupt controller has fast access and they had.
But imagine something like an I/O expander on an I2C bus.
Let's assume that it supports detecting changes on its I/O inputs and also has a dedicated line to an upstream interrupt controller.
We can configure interrupt modes using I2C transactions and we can also query / mask / etc interrupt lines using I2C.
This is a real interrupt controller from all points of view and if we want to avoid polling (for potentially long time) we need to support sleeping / waiting while communicating with such controller.
At least, that's how I see it.
Jan 2 2025
Nov 27 2024
Looks goof to me.
Thank you!
In D47779#1089560, @christos wrote:I guess the same is true for PCM_RELEASE.
In D47779#1089556, @christos wrote:Alright. There are other places in the sound driver that cv_waiters is still accessed directly, so I will see how I can fix those as well.
In D47779#1089553, @christos wrote:Is there a reason (except maybe layering violations) that we do not want to do it this way and it's better to implement an additional counter in the driver?
Also, cv_wmesg is kind of semi-private and it's used only for diagnostics (tracing).
So, I don't think that it's precedent for general access to cv implementation details.
As I noted in the email thread, there is only one consumer outside of condvar implementation.
Nov 15 2024
Nov 14 2024
In D47571#1085010, @Matthew.Nygard.Dodd_gmail.com wrote:In D47571#1084984, @avg wrote:If you have added this from a diff, could you please re-do the diff with -U 9999 option?
That's to have a lot more context lines which would be useful when reviewing.Done.
If you have added this from a diff, could you please re-do the diff with -U 9999 option?
That's to have a lot more context lines which would be useful when reviewing.
Nov 1 2024
Oct 12 2024
Oct 5 2024
Sep 25 2024
Oh, thinking about this triggered some old memories and I've dug up my old musings on this topic.
The code was never really tested and I cannot guarantee that it's correct, but it seemed correct to the younger me and it still seems correct the now me.
https://people.freebsd.org/~avg/wfhandler.v8.h
In D46421#1066706, @avg wrote:Another general suggestion is that using CK_SLIST from ConcurrencyKit (included into FreeBSD) might help to make the code more compact and expressive.
But I haven't thought through details, so please feel free to ignore this suggestion if CK does not provide something that could be readily used.
The proposed code is completely good too.
Another general suggestion is that using CK_SLIST from ConcurrencyKit (included into FreeBSD) might help to make the code more compact and expressive.
But I haven't thought through details, so please feel free to ignore this suggestion if CK does not provide something that could be readily used.
The proposed code is completely good too.
I am not sure that such a OS/ACPI (firmware) mutex is possible.
Sep 19 2024
My only concern with the current deregistration approach is a hypothetical situation where a handler resides in a loadable module and, thus, can be unloaded after deregistration.
I like the clever simplicity of the current code where list elements are never removed and only the head pointer can ever be modified.
But maybe it would be good for nmi_remove_handler to wait for a completion of the handler if it's running.
E.g., we could add an atomic counter to struct nmi_handler which would be incremented when the handler is started and decremented when the handler is done.
Then, nmi_remove_handler could spin-wait on that counter if it's not zero (after having cleared func field to prevent future calls).
Sep 15 2024
LGTM
I like how using t_dtrace_trapframe both eliminates the search for the frame below the trap frame and the assumption on the position of the trap frame.
Aug 27 2024
Aug 12 2024
Jun 27 2024
Jun 20 2024
I would subtly change the title :-)
Otherwise, looks good to me.
Jun 14 2024
Jun 5 2024
Jun 4 2024
Looks good to me.
A bit ashamed that I could not figure that fls(x - 1) does the job if zero is handled as a special case.
Apr 21 2024
All should be done. Thank you for reporting and diagnosing the problem.
Apr 8 2024
Looks like I assumed too much without paying attention to the scratch buffer.
I'll revert the change.
Mar 16 2024
Feb 19 2024
update description
Based on earlier entries for Samsung 8x0 drives in ata_da.c and scsi_da.c it seems that a separate entry per model line was a preference.
But combing multiple entries is also okay.
However, I'd like to do it as a separate commit a bit later, unless you want to do that yourself.
Feb 18 2024
In D43961#1002853, @imp wrote:These aren't listed in Linux but I'm OK with them here
The controller is
ahci2@pci0:0:17:0: class=0x010601 rev=0x40 hdr=0x00 vendor=0x1002 device=0x4391 subvendor=0x1043 subdevice=0x84dd vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]' device = 'SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode]' class = mass storage subclass = SATA
Just want to comment that based on the errors I initially thought that the problem was a bad cable or SATA port, so I tried a few cables and a few ports on the motherboard, all with the same result.
Then I searched the internet and found some reports for the SSD model.
Then I tried attaching the SSD to an LSI SAS 2308 controller and all problem immediately went away.
Then I added the quirk and the problem got fixed for connecting to on-board SATA as well.
I should clarify that I didn't see just silent data corruption, there were read and write errors as well.
I first-hand experienced problems with a device identified as Samsung SSD 870 EVO 250GB SVT02B6Q.
I inferred that 860 is also affected based on the Linux bug report and on a similar problem with 850 as well.