Re: Installer login broken (ncurse?)

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

ader.dragonflybsd.org> <abc5f50ffd30cbc6567899ca23f25882@xxxxxxxxx> <423f2b87$0$718$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4b6e963267b965600d8081f12b08a030@xxxxxxxxx>
In-Reply-To: <4b6e963267b965600d8081f12b08a030@xxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 197
Message-ID: <423f46bc$0$719$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
NNTP-Posting-Host: 218.253.82.16
X-Trace: 1111443135 crater_reader.dragonflybsd.org 719 218.253.82.16
Xref: crater_reader.dragonflybsd.org dragonfly.bugs:3929

Jasse Jansson wrote:

> 
> On Mar 21, 2005, at 9:15 PM, Bill Hacker wrote:
> 
>> Jasse Jansson wrote:
>>
>> *SNIP*
>>
>>> The only thing I have disabled in the BIOS is the SIL 3114
>>> SATA controller, because disables the SCSI controller.
>>
>> ..when the SATA controller is active...
>>
>> common since WIN_DIOTS redefined everything as "SCSI"
>> that did not have fur around the edges.......
> 
> 
> Sure, but some people running Solaris10/x64 have told me
> that they run both SCSI and SATA at the same time,
> so it MIGHT work. Not for me, but I haven't tested it much.

GigaByte MB and I-Will MB here - both Athlon,
one with onboard Promise PATA RAID,
the other with onboard HPT-372 PATA RAID
- both on-board psuedo-RAID interfere with PCI-bus
SCSI (various, RAID and non) unless optioned OFF.

BIOS coder headspace problem in both cases.
Yours may be similar.

> 
>>
>>> SCSI cont: LSI 21320R dual channel, LSI 1030 chip, mpt driver,
>>
>>
>> In the 21320R BIOS, do you presently have the twin HDD defined
>> as a RAID0, a RAID1, JBOD, or as two independent drives?
> 
> 
> I know how to do backups, so I don't need to mirror my HD's ;-)
> 

I ain't gonna touch that!

But it will reach out and touch you someday. ;-)

>>
>> If independent NOW, had they previously been defined otherwise?
> 
> 
> No.
> 
>>
>> http://www.lsilogic.com/products/scsi_hbas/lsi21320_r.html
>>
>> - relevant configuration .pdf's downloadable from the page above.
> 
> 
> Yeah, I know. I even got a CD in the box ;-)
> 
>>
>>> 2 HD's attached, both IBM 18 Gb U160 68 pin, SCSI id 0 and 1.
>>> About 1 meter U160 cable for 4 devices with a passive
>>> terminator at the end.
>>
>>
>> Should be an *active* terminator - and probably is such.
> 
> 
> Not sure, it's just a little black box with a 68 pin connector.
> When I think about it, it makes sense, passive terminators
> is a thing of the past, SCSI 2 might be the last standard
> that used them, do you know exactly when they disappeared?
> 

Mine still work...... A penurious bastid, I have used SCSI
for years 'coz it is cheapest over the long-haul.

Devices tend to last far longer that IDE, still perform
'well enough', and be *very* 'universal'.

I even have 8 & 16-bit ISA SCSI cards that still *work*.
Some industrial backplane & SBC I work with won't take
anything newer, and HDD are but one item of many that use SCSI.

Not even all storage devices can use the latest standards -
PCMCIA/Cardbus SCSI attached devices, for example.

Or even recent dual-mode gear when you simply need
longer cables and don't mind downshifting
speed and configuring from LVD to single-ended.


>>
>> Check also that the 'term power' mini-berg jumper on the
>> drives is removed.  IBM ship it in-place IIRC. Postion 4?
> 
> 
> Can't tell, have to do some more disassembly to check it.
> Hmm, should only the disk closest to the terminator have
> term power on, or should all disks have it on?
> 
NONE should need to have it on with that controller
and a properly terminated cable. The controller
will either auto-sense a need for it to terminate,
and/or have a BIOS setting to force it either way.

At the drive end, term power is for using the
drives with unterminated cables.

That said, so long as all the terminators are
'active', little harm is done.  Not so with
the older resistor packs.

>>
>>> The controller BIOS reports the both disks are on the first channel,
>>
>>
>> - Which sounds like a typical SCSI RAID implementation.
> 
> 
> Not here. This controller can be used as two independand controllers,
> a feature of the 1030 chip.
> 
Not so the venerable ASUS DA-2100, but it matters not.

They (both?) BIOS let you map anything on either channel,
or any combination to any ID+LUN on the frontside - so
the effect is comparable.

- And if LUN are used, that is a larger combination of
devices than most of us can afford to attach...

Balanced channels usually give the best speed though,
especially if you option 'write -through' instead of
'write-back' caching and/or have to operate during
a failed unit rebuild.

>>
>> > but DFly attaches them to mpt1, not mpt0.
> 
> 
> That was because I had connected them to channel B.
> Dunno why.

You have changed that since?

> 
>>
>> The *BSD's do not list a driver specifically for the
>> LSI/AMI/Symbios/NCR 1030 chipset.
> 
> 
> I mentioned mpt1 a few times ;-)
> 
Me culpa  - caught up with that too late here  ;-)

> But this has just become a moot point.
> 
> 
> DILLON, COMMIT THAT LITTLE PATCH YOU POSTED
> A FEW HOURS AGO, I'M INSTALLING DFly ON MY
> SCSI DISK RIGHT NOW!!!!!!!!!!!

Good news!  ... but had you *also* re-arranged the
drives and/or altered BIOS settings?

'The world wonders'

> 
> BTW, DFly's installer kicks FBSD's somewhere it hurts ;-)
> 
> J^2
> 

It *is* nice - but I would like to see a merge of the
better features of each.

- I really like the ability to get out to a real command
prompt in DFly, especially when I need to manage a
first-time RAID setup.  Saves one or two reboots.

- But I prefer FreeBSD's /sysinstall for a richer and
easier to *remember* toolset, especially w/r partition
and slice management, setting other options, setting up
NIC's, etc.    The 'psuedo-graphical' is handy when you
spend most time running boxen and seldom set a new
one up from scratch.

Personal preferences, I am sure, as some folks
hate /sysinstall.

More and better can be done there yet, in either case .....
. ..look at some of the Linux, or even Bluebottle installers.

Bill