Sadly, I had to revert this, with all these defines being ambiguously named I missed the fact that IN_BASE is only used in FreeBSD-specific code to signify userland/kernel differences, while IN_FREEBSD_BASE really means FreeBSD-specific code inside the common code. Will need to think more about proper approach (and naming?) here.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jun 29 2023
Jun 28 2023
Jun 19 2023
May 30 2023
May 23 2023
May 13 2023
modify spa.h instead as proposed by Warner
May 12 2023
re: stand, I don't see a call to zpool_prop_init() in there anywhere, zpool_prop.c does not seem to be compiled as well; am I missing something obvious?
I *guess* it was done this way as it's the only FreeBSD-specific part in the "common" code, and everything using IN_BASE is located under sys/contrib/openzfs/lib/libzfs/os/freebsd and sys/contrib/openzfs/include/os/freebsd proper.
May 11 2023
May 10 2023
May 9 2023
May 8 2023
May 5 2023
May 4 2023
Warner, are you OK with the explanation above?
Apr 28 2023
About my note:
In D39867#907602, @imp wrote:Is it better to fix it here, or where sc->max_targets is set? What's the source of this number, and how did it come to be off by one? And does vmware do it wrong consistently? Or is this nothing more than the 'number of targets' vs 'maximum target because we start at 0' issue other SIMs cope with?
Apr 27 2023
rebase after baseline integration
Apr 26 2023
Apr 25 2023
Apr 23 2023
Apr 21 2023
rebase on D39634
fix uninitialized variable
Apr 20 2023
move baseline file to usr.sbin/tzsetup to not clobber seemingly unrelated share/zoneinfo
Apr 19 2023
Apr 18 2023
- make -d take path to zonetab file, so that baseline target uses the zone1970.tab in src and not from installed system
- update summary to explain why ${SRCTOP}/share/zoneinfo location
In D39634#902042, @philip wrote:I like this idea, but I don't think this should live under /usr/share/zoneinfo. I believe that zoneinfo should *only* contain files generated by tzdata.
Maybe this should live in /usr/share/misc instead?
Apr 17 2023
deduplicate added code
Apr 16 2023
grrrr, sorry, really upload the updated patch
number continent entries consistently with lower-level menus
Apr 15 2023
Apr 12 2023
In D39395#899221, @schakrabarti_microsoft.com wrote:Has this change been tested?
Apr 7 2023
added IPMI_GET_MSG_DATA_NA for 0x80 magic value
Apr 6 2023
Apr 3 2023
- add sysctl to control the "fps"
- add pnp entries
- add to build
Add naive implementation of scheduled updates.
Mar 31 2023
Mar 28 2023
Sorry, I completely forgot about this review, and now another PR was filed for the same problem. Could you please take another look? (I have updated the test case a bit for more complete switch testing).
update the test case to make it cover all switches between these locales
add the spdx identifier
Mar 27 2023
May 6 2021
Apr 24 2021
Apr 19 2021
In D29584#669299, @papani.srikanth_microchip.com wrote:In D29584#668301, @yuripv wrote:With this patch applied, it fails much faster for me completely locking up ZFS, usually after some minutes of light load (e.g. I was doing git gc when this happened):
[ERROR]::[4:655.0][CPU 0][pqisrc_heartbeat_timer_handler][178]:controller is offline (da1:smartpqi0:0:65:0): WRITE(10). CDB: 2a 00 05 82 4f e0 00 07 e8 00 (da2:smartpqi0:0:66:0): WRITE(10). CDB: 2a 00 05 82 7d 98 00 00 58 00 (da1:smartpqi0:0:65:0): CAM status: Unable to abort CCB request (da1:smartpqi0:0:65:0): Error 5, Unretryable error (da1:smartpqi0:0:65:0): WRITE(10). CDB: 2a 00 05 82 67 98 00 07 e8 00 (da1:smartpqi0:0:65:0): CAM status: Unable to abort CCB request (da1:smartpqi0:0:65:0): Error 5, Unretryable error ... da0 at smartpqi0 bus 0 scbus0 target 64 lun 0 da0: <ATA WDC WD40PURZ-85A 0A80> s/n WD-WX32D7088CCV detached (da1:smartpqi0:0:65:0): Error 5, Unretryable error (da1:smartpqi0:0:65:0): WRITE(10). CDB: 2a 00 05 82 38 28 00 07 e8 00 (da1:smartpqi0:0:65:0): CAM status: Unable to abort CCB request (da1:smartpqi0:0:65:0): Error 5, Unretryable error da1 at smartpqi0 bus 0 scbus0 target 65 lun 0 da1: <ATA WDC WD40PURZ-85A 0A80> s/n WD-WX42D70CHZS7 detached (da2:smartpqi0:0:66:0): CAM status: Unable to abort CCB request (da2:smartpqi0:0:66:0): Error 5, Unretryable error (da2:smartpqi0:0:66:0): WRITE(10). CDB: 2a 00 05 82 75 b0 00 07 e8 00 (da2:smartpqi0:0:66:0): CAM status: Unable to abort CCB request (da2:smartpqi0:0:66:0): Error 5, Unretryable error da2 at smartpqi0 bus 0 scbus0 target 66 lun 0 da2: <ATA WDC WD40PURZ-85A 0A80> s/n WD-WXC2D90D7YAX detached da3 at smartpqi0 bus 0 scbus0 target 67 lun 0 da3: <ATA WDC WD40PURZ-85A 0A80> s/n WD-WX12DB0N8F4X detached ses0 at smartpqi0 bus 0 scbus0 target 68 lun 0 ses0: <Adaptec Smart Adapter 3.53> s/n 7A4263EAB3E detached pass5 at smartpqi0 bus 0 scbus0 target 1088 lun 1 pass5: <Adaptec 1100-8i 3.53> s/n 7A4263EAB3E detached (ses0:smartpqi0:0:68:0): Periph destroyed (pass5:smartpqi0:0:1088:1): Periph destroyed Solaris: WARNING: Pool 'data' has encountered an uncorrectable I/O failure and has been suspended. Apr 16 11:36:45 sun ZFS[45956]: catastrophic pool I/O failure, zpool=dataNow every FS access is stuck. I was able to save the kernel dump using NMI (in case we can get something interesting from it).
This same system works just fine using the same HBA, same disks, same cabling under illumos (using our internal smartpqi driver) transferring TBs worth of data, so I don't expect this to be hardware issue.
HBA is 1100-8i, disks are 4x WDC WD40PURZ SATA3 HDDs, connected using breakout cable.
Thanks for testing the changes, The lockup issue is new to us. Could you please provide the Z-Pool reproduction steps so we can reflect the setup in our lab too for testing.