> Peter Stuge wrote: >> I just don't get why all of this works under Raspbian. It really >> shouldn't, but it does. > > Pi hardware is made by a foundation sprung off Broadcom, a Fortune > 500 corporation, presumably with access to Broadcom design capacity > and/or knowledge. Pi hardware is extremely cost optimized, IMO > recklessly so, causing a few reliability issues in the past. > > Some (maybe even significant?) effort is put into raspbian by the > foundation but (I guess?) not into OpenBSD. When the hardware design > is marginal software becomes critical for reliability.
Thanks for the insight, Peter. Fair enough. I love that last sentence especially. :) I did notice that there were more interrupts when using the second port, and that for some reason the USB hub would be recognized in reverse order (USB3 before USB2) compared to the first port (USB2 before USB3). But that doesn't tell me much. So what's the correct procedure for figuring out where the code hangs? I remember years ago (in an enterprise software world) we'd repeatedly trigger thread dumps of our Java apps to see which code we'd see most often, and from that deduct where the bottlenecks were. Old skool, but it worked. I'm wondering what the equivalent would be in the kernel. When I trigger the system to slowly freeze ... what's the proper procedure to take "snapshots" of the internals? kstat, ktrace, magic? Happy to take a couple of RTFMs home! :-P Cheers, Torben
