I'm so glad that my hit-and-run post has been so useful. After seeing Fabien's blog post I did a quick search and it turns out that the solution has spread fairly broadly to other forums. My choice of 0x33 was arbitrary so makes a nice canary for seeing it spread out. I'm thrilled. Sharing experiences and solutions is so essential to learning. I've benefited enormously from the generosity of open source developers and communities and from individuals documenting pieces of their projects, glad to have raised the ocean a little in return.
My use case was (and remains) having a Xilinx Artix 7 FPGA in an external Thunderbolt 3 enclosure for testing the development of DSP accelerators using open source tooling. I didn't want to have the FPGA board inside the PC to be able to swap it to my laptop easily, because it produces a lot of heat, and so when I misused the PCIe soft core (litePCIe: https://github.com/enjoy-digital/litepcie/) it doesn't take down the OS. Being able to reload the FPGA and effectively hotplug the device has been very helpful.
Since I knew my issue was around hotplugging I searched for information around PCIe hotplugging and I think (it was two years ago...) that I found the answer from one of these two threads. Both mention the option of reserving PCIe addresses for hotplug busses as a workaround, and a workaround was all I needed.
dmesg and the various kernel logs are my first stop for any odd behavior on Linux. Especially with any state change to a device (plugging in, turning on, removing, reconfiguring etc) the kernel logs tend to give invaluable info.
I had already been looking at eGPU forums to choose the Thunderbolt 3 enclosure (ended up with the ORI-SCM2T3-G40-GY) and there were various discussions of hotplugging issues there, but I don't think I found the specific kernel options to fix it there.
For the string "pci=realloc,assign-busses,hpbussize=0x33"
`realloc`
Enable/disable reallocating PCI bridge resources if allocations done by BIOS are too small to accommodate resources required by all child devices.
assign-busses
[X86] Always assign all PCI bus numbers ourselves, overriding whatever the firmware may have done.
`hpbussize=nn`
The minimum amount of additional bus numbers reserved for buses below a hotplug bridge. Default is 1.
0x33 (decimal 51) is arbitrary, but large enough that I was unlikely to ever exhaust that address range even with a large number of devices chained together on the Thunderbolt bus. I think (though would have to check) that the address space does get exhausted with multiple hotplug cycles. I haven't hit that issue since I shutdown the computer close to daily to save power.
Sadly, there's no Segway, those things are expensive and I have a long wish list before reaching that point. Currently I'm saving up to get a microscope, I have a large box of RF integrated circuits that I'd like to do some show and tell with on Twitch. :) Also no unmarked 40% keyboard, RSI means I'm a total fanboy of the Microsoft Ergonomic keyboard and the Anker vertical mouse. Cheap and so comfortable. I have done some kernel compiling, mostly to learn more about kernel modules as I've been trying to make the learning curve and user experience of experimenting with FPGAs over PCIe easier. If anyone has some experience with DKMS and creating Debs I'd welcome a chance to chat. Ditto if there's any Debian maintainer with experience packaging kernel modules, I made some headway a while back to repackage linux-gpib but got stalled out on a few of the details of maintaining patches against the upstream.
zxmth here. I'm glad to finally know that 0x33 was arbitrary :P I'm also glad that old thread on Level1 has sparked this conversation and connection around a shared Linux challenge. Thanks fabiensanglard and dkozel! Happy hot-plugging to you both!
Also I love all your retro work. I have a NeXTStation Turbo Color that's my retro pride and joy. Have you seen or been involved in any of the Demoscene activities? It's amazing the graphics that people are able to squeeze and abuse out of older hardware.
Hi dkozel, your post prompted me to look into the Microsoft Ergonomic keyboard and Anker vertical mouse as I do often feel a tiredness in the lower arms and shoulders, which I haven’t paid attention to so far, but will now.
Repetitive Strain Injury, which is an umbrella term for a ton of different conditions but they generally involve pain from doing a certain activity too much or unergonomically
No segway, I've posted a bit of a discussion above. Not all that interesting unfortunately. The error message was obscure but the problem space was pretty small so I did mostly the same thing as Fabian and searched online for related terms to PCIe hotplugging and PCIe address allocation.
Boards dev here, thanks for mentioning the app! I'd be happy to answer any questions.
Not immediately obvious, but nice to know: the *.boards file format is simply a .zip file. It contains all resources/images and an HTML file with the contents of the board so that you can access your data even without the app (I'm strong on data accessibility after getting locked out of binary data formats once too many).
So, as I understand it, you're fine with a native app which only works on a single OS, rather than one which is cross-platform and doesn't require any installation?
I AM fine with a native app that only works on a single OS. Cross-platform is not necessary, or even desired.
"Doesn't require any installation" doesn't even enter into my evaluation. The last time I cared about that was when my computer didn't have a hard drive.
The UI/UX of Boards is to my liking. Several design choices resonate with how my brain works.
That it stores its data in iCloud is to my liking.
That it doesn't require a browser is to my liking.
Well I don't know about ridiculously cheap, but I do think it's reasonable. That's not the point.
The point is that GP posted a free, offline first, cross-platform, good looking tool and OP commented saying 'well, this isn't what I'm looking for' like HN is their own personal wishlist, and then eventually finds what they're looking for, and it's not free, it's not cross-platform.
HN is not my own personal wishlist. However, it is often how I discover new and interesting things. As a result, whenever someone posts a link to a new tool or service, I tend to react to it with a personal evaluation. I rarely post a comment with my reaction; usually, it's to make a critique about a particular feature, design element, or bug that I notice.
In this case, my original comment was too succinct to be useful to anyone else, which I believe is your point. Correct me if I'm wrong on that.
Fair summary - I think perhaps a few of us just felt that the comment was a bit abrasive given the time and effort that's clearly gone into this which is being offered for free.
It looks like you see and acknowledge that opinion, which is nice, and fairly uncommon on the Internet still :)
Hope you have a good weekend and a wonderful Christmas - and it's good you found a tool that does fit your needs in the end!
This has been the most exciting software work I've seen in the last year. David is doing fantastic work. If you haven't seen anything about the development of these tools his talk at FOSDEM in February was quite good.
Hi, I'm one of the GNU Radio project officers (general busybody).
GNU Radio is used extensively in industry and academia. Hawkeye 360 and Spire use GNU Radio for satellite ground stations. Lockheed Martin, SpaceX, and a variety of other aerospace/defense use it as well for other wireless comms applications. DeepSig uses GNU Radio at least to generate test signals for their neural net based signal classification system and communication systems, possibly also internally. Analog Devices uses GNU Radio in their Scopy oscilloscope/spectrum analyzer/signal and logic analyzer application.
As said by the other commenter, check out the videos on our YouTube channel. The project is very fortunate to attract many interesting talks and speakers each year at the conference.
The Open Source Radio Telescope project hasn't setup any phased array setups yet, but the Canadian Centre for Experimental Radio Astronomy uses GNU Radio for it's phased array receivers looking at pulsars.
http://www.ccera.ca
New Mexico Tech set up a two-element array with a couple of rebuilt K-band satellite-television dishes.
I don't know what they used for the correlator.
The Array Operations Center for the EVLA (Very Large Array) and the VLBA (Very Long-Baseline Array) are on the New Mexico Tech campus; we had a lot of radio-interferometer people in town.
I follow a nearly identical flow several times a day to connect bluetooth headphones to my laptop.
- Turn on headphones
* Laptop connects immediately and uses the HSP/HFP mode (works!)
* Trying to select A2DP appears to work, but no audio will play
- Disconnect the headphones using the Bluetooth manager
- Reconnect the headphones using the Bluetooth manager
- Select A2DP, this now works.
OK, well, this had to be released before or later ;-)
Here you can find a script which automates the connection to bluetooth headphones, executing (in ruby) the steps outlined above, using the bluez commandline tool (including: retry until the connection is established...):
As usual, you need to give execution permissions, or pass it to the ruby interpreter. It's designed to executed via terminal, call it from GUI has undefined behavior.
The whole idea of the community figuring out hacks to use this hardware in ways that were never intended by its original designers, including exploiting bugs/artifacts, reminds me of the demoscene.
