confirmed fixed in 1.5-rolling-202403240925
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
All Stories
Mar 24 2024
Reopened with status "Known issue" due to revert by PR 3177.
To clearify:
Thanks will test the next release
This pretty much feels like the same issue - a fix will be present in the next 1.5 rolling release.
hardware details below
In theory that could work as a workaround as-well, it would be more precise than my current workaround, but would require the build process for my tool to download the iso, spin up a vm, and extract the info.
Sounds interesting but isn't it enough to query dpkg?
Reverted via https://github.com/vyos/vyos-1x/pull/3177
Using igb.EEE=0 or EEE=0 on the kernel commandline has no effect
My best bet would be an issue with reading back the EEE registers of the Realtek r8169 driver.
Mar 23 2024
In T6162#180836, @Apachez wrote:In T6162#180827, @ErnyTech wrote:In T6162#180826, @Apachez wrote:Wouldnt it be better if the same commit goes to Intel to be included with the out-of-tree driver which generally have better featuresupport than the in-tree driver which seems to be somewhat crippled?
That is that this commit goes into upstream to both Linux kernel and Intel out-of-tree driver (in case the later is missing this support)?
This is up to Intel as far as I know
Well sure but did you file a case and send the commit to Intel aswell?
In T6162#180827, @ErnyTech wrote:In T6162#180826, @Apachez wrote:Wouldnt it be better if the same commit goes to Intel to be included with the out-of-tree driver which generally have better featuresupport than the in-tree driver which seems to be somewhat crippled?
That is that this commit goes into upstream to both Linux kernel and Intel out-of-tree driver (in case the later is missing this support)?
This is up to Intel as far as I know
In T6162#180826, @Apachez wrote:Wouldnt it be better if the same commit goes to Intel to be included with the out-of-tree driver which generally have better featuresupport than the in-tree driver which seems to be somewhat crippled?
That is that this commit goes into upstream to both Linux kernel and Intel out-of-tree driver (in case the later is missing this support)?
Wouldnt it be better if the same commit goes to Intel to be included with the out-of-tree driver which generally have better featuresupport than the in-tree driver which seems to be somewhat crippled?
Thanks for your reply.
But I have some questions about this situation.
Because it is something different with I knew "version meaning".
Output for a standard check with section ['nat'] and for the test case above, with debug logging on; changes are correctly mirrored on secondary node:
Mar 22 2024
Tags show the code base at the step where the tag was added.
But binary can be changed since this time. For the same reason, you will not be able to build 1.1.8 or 1.2.1, etc. exactly with those binary that were on the step of tagging.
Close it as wonfix.