i just rebuilt today (8/13)'s kernel. and the kernel crashes on boot


>> NetBSD/macppc OpenFirmware Boot, Revision 1.2
>> (root@death, Thu Aug 3 19:56:52 EDT 2000)
2881532+233680 [100+105072/
(... hangs indefinitely)


anyone else here experiencing the same problem? I tried reverting back to
my 20000205 kernel and everything seems to work.


Jake



> >  Monroe Williams <monroe@pobox.com> then sayeth:
> >
> >  That's what I'm running on my 7500.  Every later kernel I've built or
> >  downloaded has been non-functional as tmpowell@yellowsub.net described.
> 
> It is functional with NetBSD current 1.4ZB 10 June 00 on our 7500
> upgraded to a PPC 604 (Revision 303).  NetBSD-current was
> non-functional from late Feb or early March until ~ 10 June, but I
> don't think that had anything to do with the SCSI subsystem.
> 
> Early on (Jan-March 99) we had a fair lot of trouble with the MESH
> system.  We had installed a 9 gig drive for NetBSD on the SCSI bus
> between the MESH controller and the ~500 Meg Quantum (MacOS) drive.
> To set up the 9 gig NetBSD drive to run we switched power to it, and
> de-switched the Quantum.  (Powered off, off course.)
> 
> That should have worked.  Unfortunately, the terminators on the
> unpowered Quantum drive were inactive (or unpowered, take your
> choice), so we would from time to time get the infamous "Panic: mesh:
> FIFO != 0" MESH message. We solved the problem by de-activating the
> Quantum terminators, re-making the SCSI cable longer and with more
> connectors (and also ensuring at least 1 foot of cable _between_
> connectors as per spec), and slapping a good, _active_ terminator on
> the end connector.  Now, our powered/unpowered drives work just fine.
> 
> Logically, the infamous "Panic: mesh: FIFO != 0" MESH message can and
> should be generated in some circumstances by bad or no termination.
> Lack of termination causes "ringing" on the line; that is, an
> assertion or de-assertion echos up and down the signal lines from the
> end of the lines. These echos can, if they happen to fall within
> certain SCSI timing specs, be interpreted by a receiver as being valid
> handshake control signals.  That would stuff the FIFO (First In, First
> Out buffer) with bogus bytes, and, for instance, make it seem we read
> a sector of 513 bytes -- one to many when it comes to the end of the
> FIFO transfer.
> 
> Also, in the early days of '99 we had big trouble if we didn't id our
> NetBSD drive SCSI 0.  If we id'd it say, 1, then some parts of the
> SCSI system would confusedly assume it was dealing with drive 0, and
> ruin your whole day.  So, we id'd both drives at 0.  I don't know if
> this has been corrected -- we don't use a second drive with NetBSD,
> and it's worked fine since.
> 
> Somebody at Apple apparently thinks that keeping the cable short
> overcomes the need to keep to spec. (and, by the way, saves on paying
> for cable).  To a point, they're correct: if you can keep the cable so
> short it's not a "signal" cable, then you don't have to worry about
> termination.  But, that's pretty darn short, and SCSI depends also on
> terminators to keep the SCSI lines at the proper voltages when some
> device is not asserting.
> 
> I looked on the motherboard, and couldn't identify terminator IC's,
> resistors, or whatever (couldn't identify much of anything really -
> maybe the good stuff is on the other side of the board;  didn't really
> want to dis-assemble the box to that extent).  So what's a 7500 got
> for termination on the MESH side?  (Can you put the MESH in the middle
> of the bus?  Don't check the documentation -- it'll tell you to take
> the whole box to your friendly local Apple dealer).  I sure don't
> know.  So, it would seem to me best to get the best termination you
> possibly can on the other end.
> 
> There are other gotchas.  The thing that was supposed to power the
> terminators on the Quantum drive is power in the cable called
> "termpwr".  This is normally provided by the "biggest guy" -- the MESH
> end in this case -- but it's up to the implementor, owner, or user (in
> that order?) to decide where termpwr is coming from.  Because, it's
> generally better to power all termination from the same source and
> voltage level, and if you don't have it, your neat stand-alone active
> terminators won't work.  But if you get _two_ sources of termpwr,
> you're in for a heck of a rough ride: then you're trying to feed two
> sources of +5V into each other; at best, that causes many strange
> problems; at worst, it causes fires.
> 
> We've blown many a SCSI termpwr fuse on our 162 cards until we found
> the small print on how to disable termpwr powering on late model
> Conner (apparently Seagate's better idea) drives. It's quite
> incredible that they were actually shipping these drives set up with
> termpwr powered from the drive by default.  Maybe lost a drive that
> way.  Don't know what people do in the real world of w*ndows.  Just
> breaks, I guess.
> 
> But the most hilarious example was a SCSI scanner (from a large and
> famous company to protect the guilty I won't name) model HP-4c we
> attempted to set up.  This critter gave us fits, just wouldn't work at
> all, until it dawned on us to check if it were providing termpwr.
> Sure enough, it was.  So, we checked the manual.  We checked all over
> the box.  We disassembled the thing.  There was _no_ _way_ _to_ _turn_
> _it_ _off_.  So, we ended up putting the scanner on the _end_ of the
> SCSI bus, (used its internal termination), split the termpwr wire out
> of the ribbon cable just before the connector to the scanner, and cut
> it out.
> 
> This works for us, it's been working fine ever since.  I don't know
> what other people do, however.
> 
> Thomas Powell <tmpowell@yellowsub.net> furthereth propound:
> 
> > I wonder if disconnecting the internal jaz would help - I can boot
> > directly into NetBSD, and after transferring all the base sets, am able
> > to untar and begin to set up the config files, but invariably end up
> > locked up with the mesh error. 
> 
> By all means, disconnect anything in site that you don't need.  (Just
> be sure it wasn't providing termination).  God only knows what these
> things might be doing.
> 
> There is a section in the FAQ which runs:
> 
>   Panic: mesh: FIFO != 0 (top)
>                  
>           If you have an external Zip drive on a machine with the MESH
>           SCSI chip, you may need to unplug the Zip drive to boot
>           successfully.
>                  
>           Some people have also seen this bug without Zip drives. One
>           person suggested that the MESH driver is more reliable if
>           you don't reboot from MacOS into NetBSD. (That is, if you're
>           running MacOS, shut down rather than rebooting, and then
>           power it back on and boot to NetBSD.)
> 
> which, if memory serves, is reflective of a number of devices that may
> or may not have worked with the MESH.  I don't know.  I have no
> intention of testing any form of Zip drive.  But it is a most
> excellent idea to rid the bus of anything you don't need.
> 
> And, anything you do need, test.  Don't assume that the manufacturer's
> have done the reasonable, or even right thing with the SCSI bus.
> Don't assume that just because a device works with MacOS, it should
> work with NetBSD; the MacOS and driver writers have massive amounts of
> time and resources, and access to documentation to tweak the software
> to hide the effects of the dollars saved on the hardware.
> 
> So, my advice:
> 
> 1.  Make sure that you have at least a good terminator on the free end
>     of the SCSI cable -- active if you can swing it.
> 
> 2.  Make sure that the terminator is powered. (termpwr).
> 
> 3.  Make sure that termpwr is provided from one and only one source.
> 
> 4.  Consider re-making your cable for more connectors and to spec.
> 
> And this is for SCSI I, II or III single-ended.  If you've got
> differential or lvd, that's a whole 'nuther story.
> 
> -Mike
>