>Interesting that we now have another drive that works when the caches
>are disabled...  When I get some free time, I'll look into that to see
>if I can figure out what's different in a transaction with a cache and
>without a cache...  If you have more time to work on this and can get
>your FPE straight, you're welcome to try and fix it before I can get to
>it.  :-)

:-) I could try, but I don't have nearly enough SCSI experience, though.
I'd be interested in helping with some other kernel hacking jobs.

>Are you sure that you don't have a buggy LC040?  I would expect the FPE
>errors to be consistent.  Your report makes it sound rather like you are
>seeing almost random failures.  To recap, some LC040 revisions have a
>hardware bug in the exception processing of F-line traps.  There is no
>workaround that I know of.

I know, about last year I was discussing the hardware bug on the list with
Ken and some others. The workaround in that case is -msoft-float.

They're consistent in that they occur at relatively the same frequencies in
the same binaries. They don't always occur in the same place.

If the bug was indeed fixed by Moto before Apple canned the 040, then I'd
expect that it is fixed in the 630 series, since that was one of the last
040 models produced.

BTW, how stable is gcc with the FPE bug? Anyone tried it?

>I doubt that vi and dt use the FPU/FPE at all.  That would be why
>they're more stable than ls or ps (which do divisions, at least).

I seem to remember that printf() uses FPU somehow...

>UVM isn't that buggy.  I'm running it (not the snapshot, though) on my
>Q700 (20MB of RAM) quite happily.

Hmm, that's weird. Maybe it's something else? Still, judging from the other
posts on the list, I'd keep UVM in a separate test track until it's proven
itself.

>> I've gotten PPP working, too, and telnet works perfectly. ftp sometimes
>> segfaults in the middle of a large download, but turning off the progress
>> bar seems to help.
>
>Makes sense.  It's probably doing FP math to draw the progress bar.

I kinda figured that too. I think the time remaining stuff uses FP math,
and it might be using printf() too?

>> Finally, I'll note what might be a security bug: /dev/adb and /dev/grf0 are
>> chmod 666 by default.
>
>This is _kind of_ a security bug.  If someone's logged on to the console
>and not running X or dt, then someone else might be able to find a way
>to really annoy them.  I don't believe either of those devices can be
>opened more than once, though, and if you make them 660 (root.wheel),
>then what if Joe User (who isn't in wheel) logs onto the console and
>tries to run X or dt?

What if Joe User who isn't in wheel logs onto ttyp0 via telnet and tries to
run X or dt?

If Joe User has to log into the console and use X or dt, then by all means
the group for that file doesn't have to remain wheel (although I think it
should be by default). But it should not be world-readable and
world-writable by default.

--
- Rolf Braun ... e-mail: rbraun@cstone.net
- Web: http://www.cstone.net/~rbraun/
- Sassy Software: cool software for your Macintosh or Apple IIgs
- Rolf's HTML & Stuff: creative web design for less

- Anyone attempting to post messages or send e-mail using my address
- without my permission will be held legally liable for forgery, and
- may be subject to legal action and severe legal penalties.