Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 Jun 95 12:15:05 MDT
From:      terry@cs.weber.edu (Terry Lambert)
To:        dillon@best.com (Matt Dillon)
Cc:        bugs@FreeBSD.org
Subject:   Re: connect() bug found and fixed (uninitialized pointer)
Message-ID:  <9506091815.AA23006@cs.weber.edu>
In-Reply-To: <199506090455.VAA14568@shell1.best.com> from "Matt Dillon" at Jun 8, 95 09:54:49 pm

next in thread | previous in thread | raw e-mail | index | archive | help
>     Here's a quick list of funky problems we've found so far, just 
>     FYI in case it rings a bell anywhere:

[ ... ]

>     * have had some problems with our HP DAT drive when DAT
>       errors occur (NCR PCI SCSI).. sometimes breaks the
>       whole scsi system.  Haven't been able to reliably
>       reproduce it yet.

I believe DAT error cause writing to other devices if you write past
EOF (I saw this on the list somewhere).

>     * our BSDI shell machine has NFS mounts to the FreeBSD
>       FTP/WWW machine so users can access their FTP/WWW partition
>       from their shell account.  If the FTP/WWW machine is
>       rebooted, the shell will 'loose' the mounts... get
>       'nfs server not responding' errors until the shell
>       is rebooted.  however, new mounting new partitions
>       during this condition still works.  Weird...

Sounds like your mounts are using TCP instead of UDP.  Changing them
to UDP should do the trick.

>     * it's pretty much impossible to setup a totally
>       new scsi disk from scratch without using sysinstall
>       to do it, and it won't do it unless you actually
>       have it install some files on the new disk.

Agreed.  There needs to be an "devadd" tool or something.

>     * would be nice if sysinstall disallowed root partitions
>       greater then whatever the BIOS limit is for bootloading
>       a /kernel (30MB or so?), or at least gave a warning.

OK, it can't allow it.

This is because the kernel is loaded by BIOS calls and the / directory
block that contains the kernel directory entry, the kernel inode,
the direct & indirect blocks for the kernel itself (and, if there is
bad144 processing, any replacement blocks that any of these blocks fall
on) must all be accessable in the C/H/S geometry for the kernel.

Basically, if you're having a problem, you've either turned off geometry
translation, or you have an older IDE or SCSI controller that can't
translate to the 8G limit in the 10/8/4 C/H/S geometry, and you'll
have to live with the limit (just like Win95 and NT, which both use
BIOS boot as well).  Your only alternative is to write controller
specific boot blocks and use them instead, or to go to a SVR4 type
/stand directory (basically, your / acts like this, but a seperate
partition just for boot info would disassociate the limit from /.


					Terry Lambert
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9506091815.AA23006>