cpenrose@sdcc13.ucsd.edu (Christopher Penrose) (01/20/91)
In article <1694@marlin.NOSC.MIL> judd@marlin.nosc.mil.UUCP (Randall R. Judd) writes: >But it is now January 19, and there has been a demo NeXTstation at the UCSD >bookstore for over a week now. I got my 040 upgrade and os 2.0 friday (January 18) from the ucsd bookstore. It was available thursday january 17. I placed my order october 11. I was disappointed with the upgrade process. I installed 2.0 first as was recommended. I used the upgrade2.0 application and it made a valiant attempt to upgrade my 1.0a harddisk. The system seemed to come up ok, so I rebooted from the 2.0 optical and put a bootblock on the harddrive. The hardware part was really easy. I brought the system up, and some bizarre behavior occurred: the system would start to accept my normal login, but then kicked me back to the login window. I ended up rebooting, and then all was cool. I was amazed that my uucp connection still worked. I then recompiled some of my own signal processing software. It didn't work. I used the old 030 binaries, and they worked fine. During this time, I discovered that that two mach processes were hogging the cpu: kern_loader (pid 3) and a <mach-task> (pid -1). Before discovering the problem with my own software. I rebooted from my 2.0 optical. The processes were no longer overworking the cpu. I checked /UPGRADEDFILES and moved in an /etc/rc file that didn't get upgraded and I rebooted. The processes were still hosing me off. I then decided to reinstall 2.0 using builddisk. I was pretty annoyed; why even include an upgrade utility if no one can use it? I strongly recommend using builddisk to upgrade to 2.0. After solving this problem, my system ran quite quick. I really like 2.0. I found some lame bugs though. My software is quite floating-point intensive. In the process of testing it, I tried the new gcc -mieee-math flag mentioned in the release notes. The program compiled fine; however, the program locked up the machine up when executed. The only respite was to use the alternate-command-* sequence. I hope I get a new 040 when they discover that this is a hardware bug. I could be wrong. I managed to figure out the hoax with my software: atof() is broken. This is really annoying, however, I solved the problem by using sscanf() instead. Things could be worse. In the process of debugging, I was comparing the output of my program with a working version I had running on a Sun 4/330 with 32 megs. I did some benchmarking: my 040 NeXTcube with 16 megs was consistently 25% faster. About bugs, Sun still hasn't fixed their ugly alloca() bug. This bug has been around for years! Things could be worse, I could own a Sun! Christopher Penrose jesus!penrose