> On 2. Mar 2021, at 02:45, Reginald Beardsley <pulask...@yahoo.com> wrote: > > > It is with deep regret that I say this. > > I shall not be working on Illumos/OI. Below is the terminal output using the > Hipster 2020.10 GUI install disk. I've always been amused by the enthusiasm > for threads. I bought John Lakos' book when it came out and unlike most > actually read much of it. I even posted a page on my office door. Many months > after I'd taken it down the entire project ground to a complete halt while > they refactored the sysem to address the linker issue I'd highlighted on my > office door. I've also read many books on operating systems and all the > issues that must be handled 100% correctly to make multiple processes running > in the same address space work reliably. Can you state the "Dining > Philospher's" problem? I can. This stuff is hard. That's why protected memory > is so important to a robust system. Threads, like shared memory are valuable > tools, but are best used with discretion. And only when there is no suitable > alternative. > > Rather well known, at least to my generation, is something called "Amdahl's > law". It's not particularly insightful. It just makes the observation that > pefectly optimizing something which does not take a lot of time has > neglegible benefit. > > That a seldom used admin utility would be rewritten as a threaded application > says that those responsible for this idiocy were solely interested in adding > "threaded programming" to their resumes. I neither know nor care if the > programmer was at fault or the manager who permitted it was at fault. In any > case it is so stupid as to begger belief. Sadly I have seen many people do > something similar. > > I have *never* written a program using pthreads or any other threading > library. I dealt with things like seismic imaging problems which ran on > 10,000 -20,000 cores or more for 8-10 days processing 10-30 TB of input and > generating similar output volumes. Fortunately these were trivially parallel > and could be broken up into separate jobs for each core. With that many > machines running, checkpointing and restarting was a critical issue. You > *were* going to lose a few machines during a run. So robust recovery was a > big deal. That much compute costs a lot of money and starting the whole thing > over simply not viable. If you did, you went out of business. The only upside > was because such users were running 50,000 cores 24x7 in a single location, > they got baseload electrical rates. Though it was not uncommon to have to > find additonal locations because the electrical power feed to that location > had been exceeded. In Houston, the AC costs as much or more than the > computers to run. > > I've seen an inappropriate tool used far too many times for the sole reason > that some one wanted to put something on their resume. For many years I'd > never written an IP based client server application. I'd taught other people > how to do it, but I had not done it myself for the simple reason that it was > not an appropriate tool for my assigned tasks. I did eventually get to write > a UDP usage logger that tracked usage statistics for the package we were > fielding. That was fun. I generated graphics that showed where each business > affiliate was in the exploration cycle from what programs they were running. > > Much too my surprise and some dismay, Mac OS X is the best supported > commercial Unix today. So I may well become a Mac user. > > A not very happy, > Reg > > jack@openindiana:/jack$ sudo /bin/su > root@openindiana:/jack# format -e > Searching for disks...done > > > AVAILABLE DISK SELECTIONS: > 0. c4d0 <drive type unknown> > /pci@0,0/pci-ide@1f,2/ide@0/cmdk@0,0 > Specify disk (enter its number): 0 >
For some unknown reason, your disks are recognized as PATA (IDE) disks and not SATA/AHCI. That alone is bad because IDE is slow and cmdk driver is not the fastest one either. You should start with checking out if AHCI (SATA) is available. That alone should not get to the crash but bad things happen. > Error: can't open disk '/dev/rdsk/c4d0p0'. Now this line is actual error - we do try to open whole disk device (*p0 is special device which does allow access to entire disk surface), but we fail. The bug there is obviously about this error - we failed to open the disk, we should not continue from this point, but we still do and the punishment is segmentation fault because some needed data structures are not properly set. It is not obvious why the disk open is failing there, the error code is not printed and you seem to have root rights. From this point, I’d run truss format and would seek out the failing open() to get the error code, perhaps it would explain. Yes, the code of format command is mess (I have been in it more than I would like to;), also we would need better tooling to handle disk partitioning, allowing easy scripting etc, something *like* freebsd gpart has been in my mind for a long time, but I haven't had time to think about it more… rgds, toomas > Segmentation Fault (core dumped) > root@openindiana:/jack# pstack core > core 'core' of 3749: format -e > --------------------- thread# 1 / lwp# 1 --------------------- > 080658cb init_globals (8095bd8, 0, 8047d18, 806837c, 0, fefc3bb9) + 51f > 08068385 c_disk (fef70548, fef70548, 3, 2, 4, 806d608) + 3c8 > 08065bc1 main (8047d6c, fef685c8, 8047da8, 8057e47, 2, 8047dd4) + 2b4 > 08057e47 _start_crt (2, 8047dd4, fefd0c6f, 0, 0, 0) + 96 > 08057d1a _start (2, 8047eb4, 8047ebb, 0, 8047ebe, 8047ed2) + 1a > --------------------- thread# 2 / lwp# 2 --------------------- > feeed05e __door_return (0, 0, 0, 0, feb90240, fef5b000) + 2e > feed287c door_create_func (0) + 4a > feee7551 _thrp_setup (feb90240) + 81 > feee7800 _lwp_start (feb90240, 0, 0, 0, 0, 0) > --------------------- thread# 3 / lwp# 3 --------------------- > feee7859 __lwp_park (8097828, 8097838, 0, 0, 0, 0) + 19 > feee1607 cond_wait_queue (8097828, 8097838, 0) + 5f > feee1d82 __cond_wait (8097828, 8097838) + b1 > feee1e1c cond_wait (8097828, 8097838) + 2e > fe8a4986 subscriber_event_handler (8095ce0) + 9d > feee7551 _thrp_setup (feb90a40) + 81 > feee7800 _lwp_start (feb90a40, 0, 0, 0, 0, 0) > root@openindiana:/jack# > > > > _______________________________________________ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
