Re: 8ee579abe09e - main - zfs: fall back if block_cloning feature is disabled

Cy, The patch adds 'bool done_outvp', unconditionally sets it to 'true', and then later has a check for 'if (!done_outvp)'. Since there is no intervening place where 'done_outvp' could be set to 'false', that check will never succeed and that branch is unreachable. Or am I mis-reading

Re: 8ee579abe09e - main - zfs: fall back if block_cloning feature is disabled

Cy, The patch adds 'bool done_outvp', unconditionally sets it to 'true', and then later has a check for 'if (!done_outvp)'. Since there is no intervening place where 'done_outvp' could be set to 'false', that check will never succeed and that branch is unreachable. Or am I mis-reading

Re: 885db9301ef9 - main - qlnx: Comment out remaining references to tx_data_bd.

-Original Message- From: John Baldwin Date: 2022-04-08, Friday at 12:27 To: Ravi Pokala , , , Subject: Re: git: 885db9301ef9 - main - qlnx: Comment out remaining references to tx_data_bd. On 4/7/22 6:40 PM, Ravi Pokala wrote: > -Original Message- > From: on behalf

Re: 885db9301ef9 - main - qlnx: Comment out remaining references to tx_data_bd.

-Original Message- From: John Baldwin Date: 2022-04-08, Friday at 12:27 To: Ravi Pokala , , , Subject: Re: git: 885db9301ef9 - main - qlnx: Comment out remaining references to tx_data_bd. On 4/7/22 6:40 PM, Ravi Pokala wrote: > -Original Message- > From: on behalf

Re: 3781e77995e9 - main - riscv: actually enable sanitizers

Hi Piotr, > --- a/lib/Makefile > +++ b/lib/Makefile > @@ -184,7 +184,7 @@ SUBDIR.${MK_STATS}+= libstats > .if ${COMPILER_TYPE} == "clang" && ${MK_CXX} != "no" && \ > (${MACHINE_CPUARCH} == "aarch64" || ${MACHINE_CPUARCH} == "amd64" || \ > ${MACHINE_CPUARCH} == "arm" ||

Re: 3781e77995e9 - main - riscv: actually enable sanitizers

Hi Piotr, > --- a/lib/Makefile > +++ b/lib/Makefile > @@ -184,7 +184,7 @@ SUBDIR.${MK_STATS}+= libstats > .if ${COMPILER_TYPE} == "clang" && ${MK_CXX} != "no" && \ > (${MACHINE_CPUARCH} == "aarch64" || ${MACHINE_CPUARCH} == "amd64" || \ > ${MACHINE_CPUARCH} == "arm" ||

Re: svn commit: r353418 - in stable/10/sys: conf dev/cxgbe dev/cxgbe/common dev/cxgbe/firmware modules/cxgbe/t4_firmware modules/cxgbe/t5_firmware modules/cxgbe/t6_firmware

Requested by: Panasas Thanks Navdeep! :-) -Ravi (wearing Panasas hat) -Original Message- From: on behalf of Navdeep Parhar Date: 2019-10-10, Thursday at 16:27 To: , , , Subject: svn commit: r353418 - in stable/10/sys: conf dev/cxgbe dev/cxgbe/common dev/cxgbe/firmware

Re: svn commit: r353418 - in stable/10/sys: conf dev/cxgbe dev/cxgbe/common dev/cxgbe/firmware modules/cxgbe/t4_firmware modules/cxgbe/t5_firmware modules/cxgbe/t6_firmware

Requested by: Panasas Thanks Navdeep! :-) -Ravi (wearing Panasas hat) -Original Message- From: on behalf of Navdeep Parhar Date: 2019-10-10, Thursday at 16:27 To: , , , Subject: svn commit: r353418 - in stable/10/sys: conf dev/cxgbe dev/cxgbe/common dev/cxgbe/firmware

Re: Intel D-2146NT SoC Support (not D-2164NT)

> From: Lyndon Nerenberg > To: freebsd-hardware@freebsd.org > Subject: Intel D-2146NT SoC Support (not D-2164NT) > Message-ID: <42acae514ff06...@orthanc.ca> > Content-Type: text/plain; charset="us-ascii" > > Lyndon Nerenberg writes: >> We're looking a buying a Supermicro system with the

Re: svn commit: r297374 - head/sys/x86/x86

Hi Kib, -Original Message- From: on behalf of Konstantin Belousov Date: 2016-03-29, Tuesday at 01:44 To: , , Subject: svn commit: r297374 -

Re: svn commit: r297374 - head/sys/x86/x86

Hi Kib, -Original Message- From: on behalf of Konstantin Belousov Date: 2016-03-29, Tuesday at 01:44 To: , , Subject: svn commit: r297374 -

Re: Low-level trace-buffers in CAM

-Original Message- From: John Baldwin Date: 2015-11-24, Tuesday at 18:07 To: "freebsd-hack...@freebsd.org" Cc: Adrian Chadd , Ravi Pokala , "freebsd-geom@freebsd.org"

Re: svn-src-head Digest, Vol 141, Issue 28

Hi Adrian, This: +#ifdef ARGE_DEBUG + for (i = 0; i < 32; i++) { + if (status & (1 << i)) { + sc->intr_stats.count[1 << i]++; + } + } +#endif looks wrong. If "status" has value 0x0080, then the above will try to increment index 128,

Re: Low-level trace-buffers in CAM

eebsd.org>, "freebsd-hack...@freebsd.org" <freebsd-hack...@freebsd.org>, "k...@freebsd.org" <k...@freebsd.org>, "i...@freebsd.org" <i...@freebsd.org>, "sco...@freebsd.org" <sco...@freebsd.org> Subject: Re:

Re: Low-level trace-buffers in CAM

-Original Message- From: Ravi Pokala Date: 2015-10-26, Monday at 21:21 To: Adrian Chadd Cc: "freebsd-geom@freebsd.org" , "freebsd-s...@freebsd.org" , "freebsd-hack...@freebsd.org"

Low-level trace-buffers in CAM

Hi folks, This is an updated re-send of a message I originally sent about a year ago, during MeetBSD 2014. A few people expressed interest in person, but no one ever followed up on the lists. I'm bringing this up again, in the

Re: Low-level trace-buffers in CAM

-Original Message- From: Scott Long Date: 2015-10-26, Monday at 20:08 To: Ravi Pokala Cc: "freebsd-geom@freebsd.org" , "freebsd-s...@freebsd.org" , "freebsd-hack...@freebsd.org"

Re: ECC support

-Original Message- >Date: Thu, 22 Oct 2015 11:09:50 -0700 >From: John Baldwin >To: freebsd-hardware@freebsd.org >Cc: Dieter BSD , freebsd-hack...@freebsd.org >Subject: Re: ECC support >Message-ID: <1492434.22kxskh...@ralph.baldwin.cx>

Re: FreeBSD LAG LACP timeout tunable through IOCTL

Hi LN, You also need to teach `ifconfig' how to toggle this new setting. See sbin/ifconfig/iflagg.c:lagg_cmds[] and how the other LACP options are handled. (Thanks to Genesys on #bsdcode for pointing that out.) Also, please confirm that you don't need to do any locking to walk the list or

Performance issues with Intel Fortville (XL710/ixl(4))

Hi folks, At Panasas, we are working with the Intel XL710 40G NIC (aka Fortville), and we're seeing some performance issues w/ 11-CURRENT (r282653). Motherboard: Intel S2600KP (aka Kennedy Pass) CPU: E5-2660 v3 @ 2.6GHz (aka Haswell Xeon) (1 socket x 10 physical cores x 2 SMT

Re: freebsd-hackers Digest, Vol 624, Issue 6

Date: Sat, 4 Apr 2015 02:28:46 + From: Pokala, Ravi rpok...@panasas.com To: freebsd-hardware@freebsd.org freebsd-hardware@freebsd.org, freebsd-hack...@freebsd.org freebsd-hack...@freebsd.org Subject: Booting off NVMe using traditional bootstrap? Message-ID: d1449a6e.1322b6%rpok

Booting off NVMe using traditional bootstrap?

Hi folks, Does anyone know off-hand if it's possible to boot (amd64) off of an NVMe device using the traditional bootstrap code (i.e. *not* UEFI)? Thanks, Ravi ___ freebsd-hardware@freebsd.org mailing list

Re: Converting LBAs to byte offsets through the GEOM stack

Hi Adrian, So I had a thing that I attached commands to that would funnel down to the geom layer that did this mirroring/caching/remapping thing, and it would handle schedule the commands to whatever block(s) on whatever disk(s) actually represented that particular logical offset. I actually had

Converting LBAs to byte offsets through the GEOM stack

Hi folks, When you issue a BIO, the requested byte offset (bio_offset) gets transformed by each layer of the GEOM stack as needed. If the bottom of the stack is a physical disk, g_disk_start() transforms the final offset to a device block address (bio_pblkno), which the disk device driver uses as

Re: Converting LBAs to byte offsets through the GEOM stack

I've only done this manually... It isn't too hard, as all the partitioning schemes are simple offsets, and the stripe should be regular... The *partitioning schemes*, yes. But once you start building up more layers, it gets complicated. The issue w/ manually mapping, is that you might loose a

Low-level trace-buffers in CAM

Hi folks, At Panasas, we found it useful to have a trace buffer for each ATA drive in the system, for gathering information about command sequences and latency. I implemented that functionality for our old 7-ish ATA driver, and it works quite well, with fairly low overhead. For example (sorry for

Re: Differences between disk controllers

Date: Mon, 10 Mar 2014 22:52:16 +0100 From: Willem Jan Withagen w...@digiware.nl To: hardw...@freebsd.org Subject: Differences between disk controllers Message-ID: 531e3410.5090...@digiware.nl Content-Type: text/plain; charset=ISO-8859-1 Hi, Running: FreeBSD 10.0-STABLE #0 r262730 I've