- User Since
- Aug 29 2014, 12:11 PM (242 w, 1 d)
Is there a notification for when we are fully seeded the first time and entropy is available? FlowIDs are a controversial subject as to what they mean and what they are good to use for (see various RFCs and drafts, especially from Brian Carpenter in the last years). BSD enable random flowids by default but we could equally, if not set by application, leave them 0 for the first few packets.
Fri, Apr 19
Again, can you you please mention rip6_input() in the commit message?
Again can you please mention "... in rip6_input() ..." in the commit message.
Can you please improve the description before committing stating that it's related to rip6_output().
This seems like four different issues and it's kind of hard to keep them apart in a single change. For the sake of having a readable history and easily seeing/understanding each problem, can you please split them up?
Thu, Apr 18
That said, there are vendors who list it (maybe not on the forwarding plane) but as RFC compliance supporting it:
I'l resign as a reviewer from this as removing valid RFC support seems counter-intuitive to me just because currently to your best knowledge no device supporting it exists. Someone should write the draft first to deprecate this and see if people stand up and then remove it.
Mon, Apr 15
I think this looks fine now. I haven't given it a full read-down or test again (just going by the diff of changes and last comments).
Sat, Apr 13
I only scrolled through and what I saw looked ok to me.
Sat, Apr 6
Scrolling through the kernel changes it looks good to me; not done an in-detail review on them.
OK, this seems fine to me.
Wed, Apr 3
Tue, Apr 2
Mon, Apr 1
The descriptions needs slightly rewording "is requested". I'd be a bit more verbose maybe explaining distinct use of block_size and block_count?
This is missing files I think. The mmcreg.h structure changes are missing from this one. This won't compile.
Sun, Mar 31
Use the correct field `sim_dev`` not `sim``.
Last minute cleanup changes are never a good idea without compiling/booting them,
@imp if you can confirm that the two changes (usdbdevs.awk -> sdiodevs.awk) and the disclaimers should be added I'll be happy to go ahead.
Fri, Mar 29
Just adding three comments to point out the not-so-obvious obvious apart from the fact that
(a) unloading is not yet supported.
(b) a man page is missing.
Will be handled as part of kibab's D19674 .
Thu, Mar 28
Can we break this up into 2-3 changes please?
(1) Adding block_size and block_count to mmcreg.h and fixing the initialiers with memset or = 0; these changes are by themselves and undisputed and could get out of this.
(2) The change to the #defines in mmcreg.h can go in as well; they are not all strictly related to blk count from what I can see, so keeping them on their own would be nice.
The interrupt issues I am still seeing on CRC DAT errors seem specific to the broadcom chip on the RPi. I found other references. I have not been able to track down a solution yet but I'd suggest we ignore that for the moment.
I've got three proposed changes. The first two hunks remove a timeout interrupt here (unsurprisingly) by using a correct block size.
Wed, Mar 27
Seems fine to me. I keep running into that at boot and have yet to figure out why transmit is not possible at that point yet; it kills the first IPv6 RS/IPv4 DHCP packet (but that's for another review).
Fri, Mar 22
For your information; sdhci_data_irq() needs more love. Currently it runs into the CRC error case which is wrong when I am trying to blk_count = 511 (yes I am avoiding blk_count = 0 for infinite). I haven't looked into it yet, but it'll be next; here's a short debug trace:
DBG: brcmf_sdiod_ramrw:283: write 32768/600487 bytes at offset 0x00000000 in window 0x00198000 sdhci_bcm0-slot0: Got XPT_MMC_IO sdhci_bcm0-slot0: CMD53 arg 0x9d0001ff flags 0x35 dlen 32704 dflags 0x9 blksz=64 blkcnt=511 sdhci_bcm0-slot0: SDIO Custom block params: blksz: 0x40, blk cnt: 0x1ff sdhci_bcm0-slot0: Blk size: 0x00000040 | Blk cnt: 0x000001ff sdhci_bcm0-slot0: Starting command opcode 0x35 flags 0x3a sdhci_bcm0-slot0: Interrupt 0x11 sdhci_bcm0-slot0: sdhci_finish_command: called, err 0 flags 0x35 Resp: 0x1000 0000 0000 0000 sdhci_bcm0-slot0: Interrupt 0x208010 sdhci_bcm0-slot0: sdhci_data_irq:2174 set error 0x02 intmask 0x200010 ^^^^^^^^^^^^^^^^^^
I haven't convinced myself yet that these two extra fields are actually needed but meanwhile this is needed (independently). I'll put it into a proper review later tonight.
Mar 21 2019
Do you have a quick overview of what all gets completely flushed this way? Hmm IP (reassmbly), frag6, sctp, and tcp is what I can spot, are there others?
Mar 20 2019
Mar 19 2019
While this solves the immediate problem you were experiencing at some collateral damage for all other interfaces, it doesn't solve the underlying issues for all places, like the netisr queue.
Mar 17 2019
Mar 16 2019
Mar 15 2019
Sorry Kyle, that the full discussion on this is now done on this review. Thanks for starting to consolidate all the "random" uses.
Let's take this slowly and try to get it righter and with rough consensus into something which will (a) sort the various individual implementations, and (b) solve problems for our users.
Mar 14 2019
Mar 13 2019
Mar 9 2019
Mar 7 2019
Re-sort the struct fields to not change the expected order and use a spare field in-place. That will help netstat to continue working when updating from 12->13 without shuffling the values around.
Remove the RTSOL interface pseudo-option and run rtsol unconditionally on accept_rtadv (if it is installed).