Re: sysupgrade: add BUILDINFO file to fetched files
On Sat, May 09, 2020 at 10:51:49PM +, Mikolaj Kucharski wrote:
> @@ -1678,6 +1678,11 @@ install_files() {
> file:///mnt/var/sysmerge/${_f%%base*}etc.tgz |
> tar -zxphf - -C /mnt
> fi
> + ;;
> + BUILDINFO)
> + # Keep BUILDINFO for sysupgrade(8).
> + $_unpriv ftp -D Installing -Vmo - \
> + "$_fsrc" >"/mnt/var/db/installed.BUILDINFO"
> ;;
> *) # Make a backup of the existing ramdisk kernel in the
> # bsd.rd only download/verify/install case.
This needs more work, above doesn't work with upgrade path, when
BUILDINFO is missing. For example /home/_sysupgrade/ is prepared
via sysupgrade(8) which doesn't yet know how to fetch BUILDINFO.
--
Regards,
Mikolaj
[patch] pkg_info -C doesn't show usage without pkg-name
display usage() if pkg_info -C issued without package name provided
Index: PkgInfo.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PkgInfo.pm,v
retrieving revision 1.50
diff -u -p -u -r1.50 PkgInfo.pm
--- PkgInfo.pm 19 Feb 2020 14:23:26 - 1.50
+++ PkgInfo.pm 10 May 2020 01:37:14 -
@@ -608,7 +608,7 @@ sub parse_and_run
my $nonames = @ARGV == 0 && @extra == 0;
- unless ($state->hasanyopt('cMUdfILRsSP')
+ unless ($state->hasanyopt('cCMUdfILRsSP')
if ($nonames) {
if ($state->opt('Q')) {
$state->setopts('I');
Re: sysupgrade: add BUILDINFO file to fetched files
Hi Stuart,
On Thu, Apr 16, 2020 at 11:53:19AM +0100, Stuart Henderson wrote:
> Rather than downloading it and deleting it again, it would be more
> useful if BUILDINFO was kept around after installing. Then sysupgrade
> could check to make sure it isn't going backwards with a future update.
> (e.g. if some malicious mirror or mitm intentionally serves an old
> snapshot [with a good signature] to prevent users getting a security
> fix).
>
> I started looking at this a while ago and have had this in my tree (I'd
> forgotten about until I just did a cvs up) - maybe worth some more thought
> (it's not super-robust but I'm not sure if it needs to be..) ENOTIME to
> look at it more now though.
I really like it. I've looked into miniroot directory to implement
bsd.rd part needed for sysupgrade(8) changes. Diff at the end of this
email.
> Index: usr.sbin/sysupgrade/sysupgrade.sh
> ===
> RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
> retrieving revision 1.37
> diff -u -p -r1.37 sysupgrade.sh
> --- usr.sbin/sysupgrade/sysupgrade.sh 26 Jan 2020 22:08:36 - 1.37
> +++ usr.sbin/sysupgrade/sysupgrade.sh 16 Apr 2020 10:40:37 -
> @@ -131,6 +131,7 @@ cd ${SETSDIR}
>
> echo "Fetching from ${URL}"
> unpriv -f SHA256.sig ftp -N sysupgrade -Vmo SHA256.sig ${URL}SHA256.sig
> +unpriv -f BUILDINFO ftp -N sysupgrade -Vmo BUILDINFO ${URL}BUILDINFO
>
> _KEY=openbsd-${_KERNV[0]%.*}${_KERNV[0]#*.}-base.pub
> _NEXTKEY=openbsd-${NEXT_VERSION%.*}${NEXT_VERSION#*.}-base.pub
> @@ -147,11 +148,26 @@ esac
> unpriv -f SHA256 signify -Ve -p "${SIGNIFY_KEY}" -x SHA256.sig -m SHA256
> rm SHA256.sig
>
> +unpriv cksum -qC SHA256 BUILDINFO
> +
> if cmp -s /var/db/installed.SHA256 SHA256 && ! $FORCE; then
> echo "Already on latest snapshot."
> exit 0
> fi
>
> +if [[ -r /var/db/installed.BUILDINFO ]] && ! $FORCE; then
> + read _skip _skip _oldbuildtime _skip < /var/db/installed.BUILDINFO
> + read _skip _skip _newbuildtime _skip < BUILDINFO
> + if [[ $_newbuildtime -lt $_oldbuildtime ]]; then
> + echo "Snapshot on mirror is older than installed version!"
> + exit 1
> + fi
> + if [[ $_newbuildtime -eq $_oldbuildtime ]]; then
> + echo "Already on latest snapshot? Mismatch between BUILDINFO
> and SHA256?"
> + exit 1
> + fi
> +fi
> +
> # INSTALL.*, bsd*, *.tgz
> SETS=$(sed -n -e 's/^SHA256 (\(.*\)) .*/\1/' \
> -e '/^INSTALL\./p;/^bsd/p;/\.tgz$/p' SHA256)
> @@ -187,9 +203,14 @@ Set name(s) = done
> Directory does not contain SHA256.sig. Continue without verification = yes
> __EOT
>
> +# XXX should be done in bsd.rd so that this is present for a clean install
> too
> +cat <<__EOT > /etc/rc.firsttime
> +cp /home/_sysupgrade/BUILDINFO /var/db/installed.BUILDINFO
> +__EOT
> +
> if ! ${KEEP}; then
> CLEAN=$(echo SHA256 ${SETS} | sed -e 's/ /,/g')
> - cat <<__EOT > /etc/rc.firsttime
> + cat <<__EOT >> /etc/rc.firsttime
> rm -f /home/_sysupgrade/{${CLEAN}}
> __EOT
> fi
>
A bit of explanation with `cat -n install.sub | expand -t 2`
1599
1600 # Fetch and verify the set files.
1601 for _f in BUILDINFO $_get_sets; do
1602$UU && reset_watchdog
1603
I've put BUILDINFO, but I guess it could be added directly to
$_get_sets. However I think it needs to be added after baseXX.tgz set,
so directory /var/db is created before ftp tries to copy it into
/mnt/var/db.
1663
1664# Install the set files.
1665for _f in $_get_sets BUILDINFO; do
1666 $UU && reset_watchdog
1667 _fsrc="$_src/$_f"
I'm adding it at the end here, to make sure it's before baseXX.tgz, per
above explanation about /var/db.
1672 # Extract the set files and put the kernel files in place.
1673 case $_f in
I just need a basename of the set and I think using $_f doesn't
introduce any breakage.
I've tested below diff by fresh install of OpenBSD on amd64. It works
for me, file /mnt/var/db/installed.BUILDINFO is created during install
and after reboot file /var/db/installed.BUILDINFO is present on disk.
Here is output of the part which diff modifies:
Set name(s)? (or 'abort' or 'done') [done]
Get/Verify SHA256.sig 100% |**| 2141 00:00
Signature Verified
Get/Verify BUILDINFO100% |**|54 00:00
Get/Verify bsd 100% |**| 18117 KB02:30
Get/Verify bsd.rd 100% |**| 10109 KB00:29
Get/Verify base67.tgz 100% |**| 238 MB13:57
Get/Verify comp67.tgz 100% |**| 74451 KB02:54
Get/Verify man67.tgz100% |**| 7464 KB00:19
Get/Verify game67.tgz 100% |**| 2745 KB00:07
Get/Verify xbase67.tgz 100% |**| 22912 KB00:58
Get/Verify xshare67.tgz 100% |
Re: 6.7 snaps upgrade went fine - Intel ax200ngw not so much
On Sat, May 9, 2020 at 4:14 AM Stefan Sperling wrote: > On Fri, May 08, 2020 at 11:51:50AM -0400, sven falempin wrote: > > I upgraded to 6.7 - beta a tftp server i use > > > > Not much to report as the device is basic but i wanted to test some wifi > on > > it. > > > > iwx0 at pci8 dev 0 function 0 "Intel Wi-Fi 6 AX200" rev 0x1a, msix > > > > The firmware crashes at start, > > It looks like a failure of the NVM_ACCESS command: > > > iwx0: 0x00050088 | last host cmd > > #define IWX_NVM_ACCESS_CMD 0x88 > > > no config down: > > What does "no config down" mean? > > If you could provide an exact sequence of steps anyone without prior > knowledge > could perform in order to repeat this problem, then I would take a look. > Please don't assume that I already knew. I have never seen this error. > "no config, interface is down", Did not do anything special, upgrade => Plug card => boot => crash I tested with the intel firmware it does the same. Full Dmesg : OpenBSD 6.7 (GENERIC.MP) #182: Thu May 7 11:11:58 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 7975399424 (7605MB) avail mem = 7721066496 (7363MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xebee0 (48 entries) bios0: vendor American Megatrends Inc. version "F2" date 06/20/2014 bios0: Gigabyte Technology Co., Ltd. AM1M-S2H acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT CRAT SSDT acpi0: wakeup devices BR11(S4) GPP0(S4) GPP1(S4) GBE_(S4) GPP2(S4) GPP3(S4) SBAZ(S4) PS2K(S3) OHC1(S4) EHC1(S4) OHC2(S4) EHC2(S4) OHC3(S4) EHC3(S4) XHC0(S4) PWRB(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Athlon(tm) 5350 APU with Radeon(tm) R3, 2046.44 MHz, 16-00-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Athlon(tm) 5350 APU with Radeon(tm) R3, 2046.17 MHz, 16-00-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Athlon(tm) 5350 APU with Radeon(tm) R3, 2046.17 MHz, 16-00-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Athlon(tm) 5350 APU with Radeon(tm) R3, 2046.17 MHz, 16-00-01 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT cpu3: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu3: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu3: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 5 pa 0xfec0, version 21, 24 pins ioapic1 at mainbus0: apid 6 pa 0xfec01000, version 21, 32 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0:
Re: diff: em(4) deadlock fix
On Fri, May 08, 2020 at 04:36:28PM +0200, Mark Kettenis wrote: > > Date: Fri, 8 May 2020 15:39:26 +0200 > > From: Jan Klemkow > > On Mon, Apr 27, 2020 at 10:42:52AM +0200, Martin Pieuchot wrote: > > > So the current logic assumes that as long as the ring contains descriptors > > > em_rxrefill() failures aren't fatal and it is not necessary to schedule a > > > refill. Why? > > > > I'm not sure. I just figured out, what I described below. > > > > > Unless we understand this it is difficult to reason about a fix. Have > > > you looked at other drivers, is it a common pattern? > > > > Drivers like iavf(4) and ixl(4) just set the timeout when the alive > > (if_rxr_inuse returns) counter is 0. Other drivers like ix(4) and > > bnx(4) call the timeout, when refill was not possible. > > > > I adjust the patch to the behavior of ix(4). (see below). > > > > > > In my case, the function em_rxeof is unable to pull the last one or two > > > > mbufs from the receive ring, because the descriptor status hasn't set > > > > the "descriptor done" flag (E1000_RXD_STAT_DD). Thus, the ring has one > > > > or two remaining mbufs, and the timeout to put new ones in is never set. > > > > When new mbufs are available later, the em driver stays in that > > > > situation. > > > > > > Are you saying there's always some descriptor on the ring? Did you > > > investigate why? > > > > Yes, with printf-debugging: I see that we return from em_rxeof() > > because the status bit E1000_RXD_STAT_DD is not set. And systat(8) > > shows one or two remaining mbufs in the ALIVE column. > > > > > > The diff always sets the timeout to put new mbufs in the receive ring, > > > > when it has lesser mbufs then the "low water mark". > > > > > > This changes the logic explained above. With it the fatal condition > > > changes from 0 to `lwm'. Another possible fix would be to always > > > schedule a timeout as soon as em_rxrefill() fails. > > > > I adjusted the patch to this behavior, as I mentioned above. > > > > > I'm not advocating for a particular change, I'm suggesting we understand > > > the current logic and its implications. > > > > The logic looks to me like: The NIC should first fill the last mbuf > > (descriptor), then we set a timeout to refill new mbufs (descriptors). > > It seems to me, that one or two mbufs maybe some kind of small to > > operate correctly?! > > > > But, as far as I understand the documentation of Intel, It should be > > find to deal with such a low amount of mbufs. I couldn't find any text > > that said, the firmware needs a minimum amount of DMA memory. > > Sorry, I was going to reply earlier to this mail thread. > > As far as I know, OpenBSD is the only OS that tries to run with > partially filled rings. When we started doing this we quickly found > out that there was hardware out there that didn't work with only a > single descriptor on the Rx ring. This is why we introduced the low > water mark. Should I make similar diffs for drivers that check for 0 descriptors as well? > I'm not certain if we ever found this documented unambiguously the the > hardware documentation available to us. But there certainly are hints > that indicate that descriptors are read a full cache-line at a time. > And if the descrioptor size is 16 bytes, you need 4 descriptors to > fill a 64-byte cache line. Good to know. > So what you were proposing in your first diff makes sense. It maight > make sense to introduce a function to check the limit though, perhaps > something like if_rxr_needfill() that returns true if the number of > descriptors on the ring is below the low water mark. What do you think of this diff, OK? Thanks, Jan Index: share/man/man9/if_rxr_init.9 === RCS file: /cvs/src/share/man/man9/if_rxr_init.9,v retrieving revision 1.7 diff -u -p -r1.7 if_rxr_init.9 --- share/man/man9/if_rxr_init.917 Nov 2017 03:51:32 - 1.7 +++ share/man/man9/if_rxr_init.99 May 2020 06:40:46 - @@ -35,6 +35,8 @@ .Fn if_rxr_put "struct if_rxring *rxr" "unsigned int n" .Ft void .Fn if_rxr_livelocked "struct if_rxring *rxr" +.Ft int +.Fn if_rxr_needrefill "struct if_rxring *rxr" .Ft unsigned int .Fn if_rxr_inuse "struct if_rxring *rxr" .Ft unsigned int @@ -88,6 +90,10 @@ receive descriptor slots to the ring. .Fn if_rxr_livelocked can signal that that receive ring is generating too much load. .Pp +.Fn if_rxr_needrefill +signals that that receive ring runs below the low watermark of descriptors and +the chip may not work properly. +.Pp .Fn if_rxr_inuse can be used to determine how many descriptor slots have been allocated on the ring. @@ -139,6 +145,7 @@ to fill them again. .Fn if_rxr_get , .Fn if_rxr_put , .Fn if_rxr_livelocked , +.Fn if_rxr_needrefill , .Fn if_rxr_inuse , and .Fn if_rxr_cwm @@ -159,6 +166,12 @@ returns the number of receive descriptor The number of descriptors may be less than the .Fa max requeste
Re: diff: em(4) deadlock fix
> Date: Sat, 9 May 2020 12:07:55 +0200 > From: Jan Klemkow > > On Fri, May 08, 2020 at 04:36:28PM +0200, Mark Kettenis wrote: > > > Date: Fri, 8 May 2020 15:39:26 +0200 > > > From: Jan Klemkow > > > On Mon, Apr 27, 2020 at 10:42:52AM +0200, Martin Pieuchot wrote: > > > > So the current logic assumes that as long as the ring contains > > > > descriptors > > > > em_rxrefill() failures aren't fatal and it is not necessary to schedule > > > > a > > > > refill. Why? > > > > > > I'm not sure. I just figured out, what I described below. > > > > > > > Unless we understand this it is difficult to reason about a fix. Have > > > > you looked at other drivers, is it a common pattern? > > > > > > Drivers like iavf(4) and ixl(4) just set the timeout when the alive > > > (if_rxr_inuse returns) counter is 0. Other drivers like ix(4) and > > > bnx(4) call the timeout, when refill was not possible. > > > > > > I adjust the patch to the behavior of ix(4). (see below). > > > > > > > > In my case, the function em_rxeof is unable to pull the last one or > > > > > two > > > > > mbufs from the receive ring, because the descriptor status hasn't set > > > > > the "descriptor done" flag (E1000_RXD_STAT_DD). Thus, the ring has > > > > > one > > > > > or two remaining mbufs, and the timeout to put new ones in is never > > > > > set. > > > > > When new mbufs are available later, the em driver stays in that > > > > > situation. > > > > > > > > Are you saying there's always some descriptor on the ring? Did you > > > > investigate why? > > > > > > Yes, with printf-debugging: I see that we return from em_rxeof() > > > because the status bit E1000_RXD_STAT_DD is not set. And systat(8) > > > shows one or two remaining mbufs in the ALIVE column. > > > > > > > > The diff always sets the timeout to put new mbufs in the receive ring, > > > > > when it has lesser mbufs then the "low water mark". > > > > > > > > This changes the logic explained above. With it the fatal condition > > > > changes from 0 to `lwm'. Another possible fix would be to always > > > > schedule a timeout as soon as em_rxrefill() fails. > > > > > > I adjusted the patch to this behavior, as I mentioned above. > > > > > > > I'm not advocating for a particular change, I'm suggesting we understand > > > > the current logic and its implications. > > > > > > The logic looks to me like: The NIC should first fill the last mbuf > > > (descriptor), then we set a timeout to refill new mbufs (descriptors). > > > It seems to me, that one or two mbufs maybe some kind of small to > > > operate correctly?! > > > > > > But, as far as I understand the documentation of Intel, It should be > > > find to deal with such a low amount of mbufs. I couldn't find any text > > > that said, the firmware needs a minimum amount of DMA memory. > > > > Sorry, I was going to reply earlier to this mail thread. > > > > As far as I know, OpenBSD is the only OS that tries to run with > > partially filled rings. When we started doing this we quickly found > > out that there was hardware out there that didn't work with only a > > single descriptor on the Rx ring. This is why we introduced the low > > water mark. > > Should I make similar diffs for drivers that check for 0 descriptors as > well? I think a full audit would indeed be good. But that can be done in a follow-up diff. > > I'm not certain if we ever found this documented unambiguously the the > > hardware documentation available to us. But there certainly are hints > > that indicate that descriptors are read a full cache-line at a time. > > And if the descrioptor size is 16 bytes, you need 4 descriptors to > > fill a 64-byte cache line. > > Good to know. > > > So what you were proposing in your first diff makes sense. It maight > > make sense to introduce a function to check the limit though, perhaps > > something like if_rxr_needfill() that returns true if the number of > > descriptors on the ring is below the low water mark. > > What do you think of this diff, OK? Looks good to me. One suggestion to improve the documentation below. ok kettenis@ but wait a couple of days to give dlg@ a chance to comment. > Index: share/man/man9/if_rxr_init.9 > === > RCS file: /cvs/src/share/man/man9/if_rxr_init.9,v > retrieving revision 1.7 > diff -u -p -r1.7 if_rxr_init.9 > --- share/man/man9/if_rxr_init.9 17 Nov 2017 03:51:32 - 1.7 > +++ share/man/man9/if_rxr_init.9 9 May 2020 06:40:46 - > @@ -35,6 +35,8 @@ > .Fn if_rxr_put "struct if_rxring *rxr" "unsigned int n" > .Ft void > .Fn if_rxr_livelocked "struct if_rxring *rxr" > +.Ft int > +.Fn if_rxr_needrefill "struct if_rxring *rxr" > .Ft unsigned int > .Fn if_rxr_inuse "struct if_rxring *rxr" > .Ft unsigned int > @@ -88,6 +90,10 @@ receive descriptor slots to the ring. > .Fn if_rxr_livelocked > can signal that that receive ring is generating too much load. > .Pp > +.Fn if_rxr_
Re: 6.7 snaps upgrade went fine - Intel ax200ngw not so much
On Fri, May 08, 2020 at 11:51:50AM -0400, sven falempin wrote: > I upgraded to 6.7 - beta a tftp server i use > > Not much to report as the device is basic but i wanted to test some wifi on > it. > > iwx0 at pci8 dev 0 function 0 "Intel Wi-Fi 6 AX200" rev 0x1a, msix > > The firmware crashes at start, It looks like a failure of the NVM_ACCESS command: > iwx0: 0x00050088 | last host cmd #define IWX_NVM_ACCESS_CMD 0x88 > no config down: What does "no config down" mean? If you could provide an exact sequence of steps anyone without prior knowledge could perform in order to repeat this problem, then I would take a look. Please don't assume that I already knew. I have never seen this error.
