I really did not want to reply to this but since some people believe that I
am just see-ing things, then I will set this straight.

I have a dual PPro-200 systems.  aha-3950u2 scsi card.  Teflon cables from
scsi-cables.com.  Segate cheetah 4.5gig drive that runs FreeBSD5.0-Current
since it came out.

I have been running FreeBSD for years...  I ran 3.0 and 4.0 when they were
/current and I never had these problems.  I cannot even get the thing
(5.0-Current in recent days) to boot from boot floppies that you put on
ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386.  If you are producing
an OS that does not boot on /current then say this publicly and not curse me
out for your production of a non functional product.  I'm sure I could
produce a set of non-functioning asm code that just crashes peoples
machines, if your idea of development is this.  I don't believe that I need
to write an email list for this.

I have a better idea, how about an option on the install to save buffer
cache to a floppy disk , or atleast the portion that caused the automatic
reboot???   Gdb anyone?

If you need more information from me about my product then please ask me and
I will say so.
-----Original Message-----
[mailto:[EMAIL PROTECTED]]On Behalf Of Thomas David
Sent: Thursday, September 28, 2000 5:33 AM
Subject: Re: interesting problem

Alfred Perlstein <[EMAIL PROTECTED]> wrote:
> * Tony Johnson <[EMAIL PROTECTED]> [000927 18:26] wrote:
> > OK
> > Well Here is the issue.  If I put in the 2 boot floppies I get a page
> > 12 after I press Q for "quit" on the visual kernel config.  If I can
save a
> > crash dump before any FS's are mounted or even before I tell FBSD where
> > put the crash dump, I'd really like to know this...   I'd like to read a
> > handbook page on thisb since some people think I just haven't read it.
> >
> > At this point in an install, if you could tell me (and the rest of the
> > FreeBSD users) where I could get the boot floppies to save a crash dump
> > (because I haven't even gotten this far) then I would appreciate this
amd be
> > more then happy to substantiate this by sending you a crash dump.
> Do you realize how much developer time you're wasting by thrashing
> around cluelessly on the list demanding help?
> Here's a clue:
> Forget about your damn irq problem, boot with the disks installed,
> then read section of the handbook about crashdumps, compile a debug
> kernel and figure out what the problem is.  Fix it and send us a
> patch.
> Or you could simply run -stable.


   Just playing `devils advocate' here.  But, in some initial
 install situations, exactly how is the user, even the most
 knowledgeable one, supposed to do much of anything if the
 install itself doesn't work?  Not too much chance of building
 a kernel, getting a crashdump, etc...

   Although it may be something we want to put off for awhile,
 being able to gather debugging information during a failed
 install would be rather nice.  I'm not sure how this could
 happen; perhaps a crashdump to an MSDOS file system (if available)?
 Or, straight to a partition with some recovery program that
 reads the dump?  Or, over a serial line?  [Just tossing out ideas.]
 Maybe ficl can get involved and manage this?

   I would keep this as one of those "maybe nice to have in the
 ideal future" ideas - but it's something to ponder...

        - Dave Rivers -

[EMAIL PROTECTED]                         Work: (919) 676-0847
Get your mainframe (370) `C' compiler at http://www.dignus.com

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to