Linux-Hardware Digest #577, Volume #9             Sat, 6 Mar 99 02:13:51 EST

Contents:
  Re: hda : irq timout problem - Any ideas? (brian whitaker)
  Re: Can Linux use 36-bit Xeon addressing? ("David A. Frantz")
  Re: S.u.S.E 5.3  and Epson Stylus Color 500 (Grant Taylor)
  Hard Disk Size Problems... ("PapaTwika")
  Re: Pentium III Boycott and survey info (mlw)
  Re: very small mainboards ([EMAIL PROTECTED])
  cpu has "F0 0F" bug? (ag)
  Microtek Scanmaker X6! (root)
  Re: PCI modem!! (Rob Clark)
  Re: Can Linux use 36-bit Xeon addressing? ("David A. Frantz")
  Linux and Cybex LongView (Neil Zanella)
  Re: Compaq Prosignia - SCSI Controller (Raymond Keith Windlow)
  GNOME (popular subject!) ("dts")
  Re: Can Linux use 36-bit Xeon addressing? (Johan Kullstam)
  Re: help with PCI modem (Newcom 56K V.90 data/fax) (Allen)
  Re: Can Linux use 36-bit Xeon addressing? (Johan Kullstam)
  Re: Xeon Processor... (Allen)
  Re: 16bit mode in XWindows (KenSiko)

----------------------------------------------------------------------------

From: brian whitaker <[EMAIL PROTECTED]>
Subject: Re: hda : irq timout problem - Any ideas?
Date: Fri, 05 Mar 1999 16:41:15 -0800

per advice from Kyle (posted to this group), i DISABLED UDMA support in
BIOS... with UDMA support built into the kernel (i'm now running
2.0.37), this problem resolved itself...

i'm running an "pegasus-1" EFA mobo with the TX chipset and a 6.8G
maxtor UDMA drive hanging off the secondary controller... i'm getting
transfer rates of 10MB/sec reliably...

brian...
. 

brian whitaker
[EMAIL PROTECTED]


Gary J Sanderson wrote:
> 
> Sometimes when reading from the hd I get the following error message;
> 
> hda : irq timeout : status=oxdo {Busy}
> hda : Disabled DMA
> ide0 : reset : success
> 
> It seems to happen more often now as well which is worrying. I'm running
> RH5.2 on a Seagate Medalist 6.5gb Ultra DMA connected to an ASUS P2B-S
> motherboard.
> 
> Any idea's how I can stop this happening? TIA, Gary.

------------------------------

From: "David A. Frantz" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux,comp.os.linux.misc
Subject: Re: Can Linux use 36-bit Xeon addressing?
Date: Fri, 5 Mar 1999 22:40:17 -0500

Hi John;

I think you hit on one problem at the very least and that is if you want to
get away from I386 you have only one other mass produced platform and that
is Apples Mac.    When dealling with software I do not think binary
compatablity is s big deal for Linux users.    After all if you want to run
something you can just recompile it.

It would be very interesting if Compag could get the price of an Alpha
motherboard down to the point where they could compete price wise.     This
is where the K7 could be a big help, we might be able to have low cost
boards that only require a EPROM / BIOS swap to switch processor families.

My point is that if you need advance architectures and are looking at the NX
chipset and trying to produce a high performance system, you should be
looking also at other soolutions that are available.    After all High
preformance I/O implies a High Performance system.     Investing in a high
performance computing system and being hung up on binary compatiablity seems
to be a little short sighted to say the least.    Now a days if you need
binary compatiablity why not look at a laptop.    If nothing else a laptop
is an excellent X-server.


Dave

John Burton wrote in message <[EMAIL PROTECTED]>...
>"David A. Frantz" wrote:
>>
>> Hi Robert;
>>
>> Robert Krawitz wrote in message ...
>> >"David A. Frantz" <[EMAIL PROTECTED]> writes:
>> >
>> >> Try this site http://humbolt.geo.uu.nl/Linux-MM/more_than_1GB.html to
>> gets a
>> >> little info on the current I386 capability.   Nothing specific on XEON
>> >> there, well at least I didn't find anything.    Sounds like your
trying
>> to
>> >> apply a low end (Yes I mean the XEON) PC chip to a project that
requires
>> a
>> >> 64 bit CPU.   You may want to consider an Alpha, or a POWERPC box from
>> IBM.
>> >
>> >I think this is a tad unfair.  I'm disappointed that Linus doesn't
>> >want to enable large memory addressing on the x86.
>>
>> As with any general purpose operateing system there are trade offs, one
>> outstanding feature of Linux is the freedom to transform it into
something
>> that suits your purposes.    The reallity is that there is nothing to be
>> gained by trying to use a special capability of the XEON just to fillfull
>> the special needs of a few users.    This is especially the case when the
>> Chip and Chip SETs are not suited for the application.    I firmly
believe
>> that if you really need 64 bit addressing to main memory then you need to
>> look at a 64 bit system.
>>
>
>There are multiple reasons for and against going with an Alpha or PPC
>vs. Intel... on of which is *all* the other hardware is Intel x86 based
>and having *binary* compatibility is important. That said, I too am
>interersted in this topic for the simple reason that the 450NX chipset
>motherboards can support 4 way interleaving of memory, plus the use of
>alternate (4 32bit PCI buses, 2 64bit PCI buses or 2 32bit & 1 64bit PCI
>buses) bus structure, up to 8 Xeon CPUs (with cluster controller)... I'm
>not as interested in the size of the address space as much as the size
>of the memory bandwidth and I/O bus structure...
>
>John
>
>--
>John Burton, Ph.D.
>Senior Associate                 GATS, Inc.
>[EMAIL PROTECTED]          11864 Canon Blvd - Suite 101
>[EMAIL PROTECTED] (personal)          Newport News, VA 23606
>(757) 873-5920 (voice)           (757) 873-5920 (fax)



------------------------------

From: Grant Taylor <[EMAIL PROTECTED]>
Subject: Re: S.u.S.E 5.3  and Epson Stylus Color 500
Date: 04 Mar 1999 18:42:34 -0500

Douglas Watts <[EMAIL PROTECTED]> writes:

> Can any one advise on a driver which would enable me to print using
> the above version? It includes Ghostscript 4.03 which does not have,
> it seems, a suitable driver.

That is correct.  Ghostscript 5.10 and 5.50 include a uniprint driver
for the Stylus 500.

-- 
Grant Taylor - gtaylor@picante<dot>com - http://www.picante.com/~gtaylor/
 Cellphone information: http://www.picante.com/~gtaylor/cell/
 Libretto information:  http://www.picante.com/~gtaylor/portable/
 Linux Printing HOWTO:  http://www.picante.com/~gtaylor/pht/

------------------------------

From: "PapaTwika" <[EMAIL PROTECTED]>
Subject: Hard Disk Size Problems...
Date: Fri, 5 Mar 1999 22:51:31 -0500

Hi,

I Just got a new 10.2 fujitsu Hard Drive, but when I try to make a linux
partition at the end of the disk, it reports -1077 Mb, as if it could not
support hard disk with more that 8 GB...

    Any Ideas?

yannick.
[EMAIL PROTECTED]



------------------------------

From: mlw <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.advocacy
Subject: Re: Pentium III Boycott and survey info
Date: Thu, 04 Mar 1999 23:21:50 +0000

Anthony D. Tribelli wrote:
> 
> [EMAIL PROTECTED] wrote:
> : [EMAIL PROTECTED] (Anthony D. Tribelli) wrote:
> 
> : >Please do so. I don't believe you'll find an undocumented reset
> : >instruction. You will probably find code that sets up BIOS to do a warm
> : >boot and then asks the keyboard controller to reset the CPU. Later methods
> : >used special I/O ports and multiple CPU faults.
> :
> : actually, what this "undocumented" reset is is simply diliberately
> : creating a triple fault.  the cpu can catch a double fault and recover
> : but the cpu resets under a triple fault situation.  the code placed at
> : the restart point is aware of what happened and gracefully recovers as
> : if just switching back to real mode.  just like has been explained.
> 
> Agreed, but it's not a simple 'instruction', and messing with the
> Interrupt Descriptor Table is not something a user level program can do.
> 
> Tony
> --
> ------------------
> Tony Tribelli
> [EMAIL PROTECTED]

No, it is a simple instruction. Not a reaset per se' but a processor
"hyperspace" instruction that reset the CPU state and read a block of
memory at (I think) 40H and continued in real mode (The ip was also
read). The purpose was testing the protected mode portion of the
processor during device testing. The processor test program needed to
get back into real mode from protected mode.

The problem was this screwed up the bios block. OS/2 had to save the
bios block, setup the future register values at 40H, execute the
instruction and copy the bios block back.

Seriously it does exist, I bet it still exists in the '386 and higher
because they run OS/2 1.x.

-- 
Mohawk Software
Windows 95, Windows NT, UNIX, Linux. Applications, drivers, support. 
Visit the Mohawk Software website: www.mohawksoft.com

------------------------------

Subject: Re: very small mainboards
From: [EMAIL PROTECTED]
Date: Fri, 05 Mar 1999 00:10:14 GMT

According to Dirk Engelmann  <[EMAIL PROTECTED]>:

> I would like to know what mainboards of very small size there are on the
> market.
> I've got no idea how thei are called and where to search.
> Especially I'm interested in mainboards which include the network card
> (and are suited to run Linux on it).

Go to wearables.stanford.edu for an example of the world smallest web
server -- about the side of a matchbox.  Follow the link to Jumptec
for a source to purchase the hardware.

-p.


------------------------------

From: ag <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc;
Subject: cpu has "F0 0F" bug?
Date: Thu, 04 Mar 1999 16:17:30 -0600
Reply-To: [EMAIL PROTECTED]

Hi all,

I've just built a machine with an Intel 233MMX cpu.  On boot, Linux
states "Intel pentium with F0 0F bug - work around enabled".  

Any info (or pointers to info) on this bug will be greatly
appreciated.....

Andrew


------------------------------

From: root <[EMAIL PROTECTED]>
Subject: Microtek Scanmaker X6!
Date: Fri, 05 Mar 1999 00:05:02 +0000

Does anybody have a Microtek Scanmaker X6 running under Linux? Need HELP
!!!!!

------------------------------

Subject: Re: PCI modem!!
From: [EMAIL PROTECTED] (Rob Clark)
Date: Sat, 06 Mar 1999 05:03:31 GMT

In article <7bq4o2$169c$[EMAIL PROTECTED]>,
Andrew Shiue <[EMAIL PROTECTED]> wrote:

>Could somebody tell me which model will be excellent in LINUX (at least
>works normally!)?

GOOD:
1) Almost all external modems that plus into a standard serial port.
2) Almost all ISA modems with jumpers that let one set the address/IRQ.

IFFY:
1) ISA modems without jumpers.  Some are Windows-only and some are not.

BAD:
1) Almost all 56K PCI modems are Windows-only.
2) USB modems are not supported yet.

For a list of modems that are known to either work or not work with Linux:

   http://www.o2.net/~gromitkc/winmodem.html

Rob Clark, [EMAIL PROTECTED]

------------------------------

From: "David A. Frantz" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux,comp.os.linux.misc
Subject: Re: Can Linux use 36-bit Xeon addressing?
Date: Fri, 5 Mar 1999 23:35:24 -0500

Hi Johan;


Johan Kullstam wrote in message ...
>John Burton <[EMAIL PROTECTED]> writes:
>
>> Johan Kullstam wrote:
>> >
>> > John Burton <[EMAIL PROTECTED]> writes:
>> >
>> > > There are multiple reasons for and against going with an Alpha or PPC
>> > > vs. Intel... on of which is *all* the other hardware is Intel x86
based
>> > > and having *binary* compatibility is important.
>> >
>> > who cares about binary compatibility?  just recompile!
>>
>> Ummm...try providing support to multiple scientists developing code on
>> their personal workstations (x86 based), running multiple jobs on
>> multiple machines, writing data to the same location (typically a
>> partition on their personal workstation), using the generated (binary)
>> data as input to other jobs on other machines...add to that the problems
>> of maintaining some type of version control over the software being
>> developed...so now add to that simply *recompiling* *all* the code that
>> has been developed, and make sure that the version of code (and
>> compilers, and libraries and utilities, and...) are the same on both the
>> x86 *and* the alpha / ppc machines... And on top of all that, the data
>> produce MUST BE CORRECT!
>
>if you want *identical* results, most of the problem is the
>bletcherous 80 bit float mode of the x86.  are you using gcc/g77?  you
>are aware that they spill the 80 bit registers into 64 temporaries.
>thus small changes in the code or fiddling with optimization switches
>can cause spillage in different places and hence small changes in the
>results.

80 bit floats are not a bad thing, it is bad for a compiler not to use them
correctly.

>
>intel should simply be avoided for any serious numerical work.

Hmm thats down right mean.    Intel should be avioded when it does fit the
application domain.    What you might want to say is that Intel is not a
cost effective way to do serious FP work.    Even a farm of Intel machines
are questionable for some applications.

>
>that said, your numerical algorithms should be designed to handle
>variations in precision.  if you have to bet that hard on the
>precision, your algorithm is ill-conditioned, i.e., broken.
>
>if you set your intel chips to do honest to god 64 bit ieee floating
>point, it will agree with the alpha.  and since both are little-endian
>machines, binary data transfer isn't that bad either.
>
>> So, while in concept having an alpha or ppc machine on the LAN with x86
>> machines is good idea, in practice there are a lot of minor problems and
>> it introduces a lot of places for bugs to enter the processing
>> setup...
>
>just using x86 all on its own introduces a lot of problems.
>
>and if you use the 36 bit address space, the new code will hardly be
>compatible with the other x86 stuff.  therefore, you still lose.
>
>> > if it's some proprietary offering, chances are it would never be
>> > offered in 32+32 bit large mode.  even if linux were to support it,
>> > it'd be a bitch to port.
>> >
>> Like I said, I don't care about the 36 bit address space, just the
>> bandwidth issue (described below) and getting the most bang for the
>> buck...
>
>i thought the whole damned point of this whole thread was the 36 bit
>address space!!!!  is the subject completely meaningless?  what is it
>you are *really* trying to say?
>
>sorry for the rant but i am sorry intel arches really lose and there's
>no fixing that.
>
>--
>                                           J o h a n  K u l l s t a m
>                                           [[EMAIL PROTECTED]]
>                                              Don't Fear the Penguin!



------------------------------

From: Neil Zanella <[EMAIL PROTECTED]>
Subject: Linux and Cybex LongView
Date: Thu, 4 Mar 1999 20:03:04 -0330


Hello,

I would like to know whether anyone has tried the Cybex LongView VGA, 
Keyboard, and Mouse extensions with their Linux system.
<http://www.cybex.com/>

How reliable are these systems? Do they work well with Linux?
How do they compare to NCD X Terminals?
<http://www.ncd.com/>
How do the hardware noise ratings compare with those of an NCD Xterm?

Thanks.

------------------------------

From: Raymond Keith Windlow <[EMAIL PROTECTED]>
Subject: Re: Compaq Prosignia - SCSI Controller
Date: Fri, 05 Mar 1999 11:59:28 +1100
Reply-To: [EMAIL PROTECTED]

If you have a look inside it uses an NCR xxxx (sorry cant recall exact
chipset number. But dont cheer just yet. We couldnt get Linux to
recognise it even when we used the drivers for the NCR either.
(We were trying to install to a machine exactly the same as yours)
Gave up in disgust !!!

Ray Windlow
[EMAIL PROTECTED]

Peter Treloar wrote:
> 
> Does anyone know what SCSI controller is on the motherboard of a Compaq
> Prosignia 486/66, and is it supported by Linux.
> 
> Windows NT reports it as a Compaq SCSI-2 controller.
> 
> Thanks,
> 
> Peter.

------------------------------

From: "dts" <[EMAIL PROTECTED]>
Subject: GNOME (popular subject!)
Date: Fri, 5 Mar 1999 12:25:05 -0500

I am having the same problem as everyone else regarding GNOME, the failed
dependencies
during install.  Also putting the exec gnome-session is not as simple as it
sounds (for me), in the
xinitrc and Xclients and also wm-style files....
i have tried different combinations,,,including inserting a line in the
Xclients and xinitrc...both...etc
I am using RedHat 5.2 .....  is there a way to manually start gnome from the
command line??
like a startx --gnome session??? ---that doesn't work for me,   I am using
Afterstep and really like it,
I am about to give up on Gnome..... it is supposed to be "revolutionary" and
increase the ease of using Linux blah blah blah.  The Gnome web page should
address the dependency problems since they are so common.
Then all of us normal users (non-gurus) can get it up and running!!! Then we
can spread the word on how great Gnome is until then.... Afterstep sure
looks nice :)
 Any help on a simple fix for the dependencies ( I did a nodep but I think
that screwed up some rpm's) because Gnome doesn't run, If I force it with a
new Xinitrc and Xclients (stripped versions) it locks up, must be missing
something.
Also... a command so I dont have to edit my X start up files (mine have
if/then and case statements... so a simple exec gnome-session doesn't work)
-Ill stop rambling,,
Thanks Dan



------------------------------

Crossposted-To: comp.os.linux,comp.os.linux.misc
Subject: Re: Can Linux use 36-bit Xeon addressing?
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 05 Mar 1999 19:18:47 -0500

John Burton <[EMAIL PROTECTED]> writes:

> Johan Kullstam wrote:
> > 
> > John Burton <[EMAIL PROTECTED]> writes:
> > 
> > > There are multiple reasons for and against going with an Alpha or PPC
> > > vs. Intel... on of which is *all* the other hardware is Intel x86 based
> > > and having *binary* compatibility is important.
> > 
> > who cares about binary compatibility?  just recompile!
> 
> Ummm...try providing support to multiple scientists developing code on
> their personal workstations (x86 based), running multiple jobs on
> multiple machines, writing data to the same location (typically a
> partition on their personal workstation), using the generated (binary)
> data as input to other jobs on other machines...add to that the problems
> of maintaining some type of version control over the software being
> developed...so now add to that simply *recompiling* *all* the code that
> has been developed, and make sure that the version of code (and
> compilers, and libraries and utilities, and...) are the same on both the
> x86 *and* the alpha / ppc machines... And on top of all that, the data
> produce MUST BE CORRECT! 

if you want *identical* results, most of the problem is the
bletcherous 80 bit float mode of the x86.  are you using gcc/g77?  you
are aware that they spill the 80 bit registers into 64 temporaries.
thus small changes in the code or fiddling with optimization switches
can cause spillage in different places and hence small changes in the
results.

intel should simply be avoided for any serious numerical work.

that said, your numerical algorithms should be designed to handle
variations in precision.  if you have to bet that hard on the
precision, your algorithm is ill-conditioned, i.e., broken.

if you set your intel chips to do honest to god 64 bit ieee floating
point, it will agree with the alpha.  and since both are little-endian
machines, binary data transfer isn't that bad either.
 
> So, while in concept having an alpha or ppc machine on the LAN with x86
> machines is good idea, in practice there are a lot of minor problems and
> it introduces a lot of places for bugs to enter the processing
> setup... 

just using x86 all on its own introduces a lot of problems.

and if you use the 36 bit address space, the new code will hardly be
compatible with the other x86 stuff.  therefore, you still lose.

> > if it's some proprietary offering, chances are it would never be
> > offered in 32+32 bit large mode.  even if linux were to support it,
> > it'd be a bitch to port.
> > 
> Like I said, I don't care about the 36 bit address space, just the
> bandwidth issue (described below) and getting the most bang for the
> buck...

i thought the whole damned point of this whole thread was the 36 bit
address space!!!!  is the subject completely meaningless?  what is it
you are *really* trying to say?

sorry for the rant but i am sorry intel arches really lose and there's
no fixing that.

-- 
                                           J o h a n  K u l l s t a m
                                           [[EMAIL PROTECTED]]
                                              Don't Fear the Penguin!

------------------------------

From: [EMAIL PROTECTED] (Allen)
Crossposted-To: comp.os.linux.setup
Subject: Re: help with PCI modem (Newcom 56K V.90 data/fax)
Date: 5 Mar 1999 01:24:04 GMT

        Officially, it's not a :Winmodem" anymore than an AMD K6 is a pentium,
since that term is trademarked, but that doesn't stop anyone from cloning the
functionality, or lack thereof.  Like the difference between "Kleenex" and
facial tissue, you have a software modem, AKA a "host controlled", or
"controllerless" modem, even if they can't legally call it a winmodem.  

        In anycase, dig your receipt out of the trash, or wherever you put it,
and promptly return it to wherever you got it from, and explain that you need a
modem that will work with CP/M86; ok, you don't need to be that obtuse, but
explain that you need a hardware based only modem, because you are running Unix,
and any modem that "requires Microsoft anything" to work won't do.  while you're
at it, you might try for one with jumpers too...  Tell them that Unix isn't
exactly PnP either.  If you just had your old one fried yesterday, I'm guessing
that you bought one over-the-counter to replace it.  If not, I'd like to know
the name of your mail-order vendor, for when I really need something in a
hurry:-))  
        BTW, I haven't yet seen a success story for anyone using a PCI modem
under Linux, though Multitech claims theirs will work, so either go external, or
ISA w/jumpers.

On Thu, 04 Mar 1999 21:07:10 GMT, [EMAIL PROTECTED] wrote:

>Hello,
>
>My old 33.6 modem got fried during the storm yesterday, so I got a new modem,
>but of course, I can't get it to work with Linux.
>
>The modem is Newcom 56k pfx data/fax PCI V.90, internal, and _not_ WinModem,
>and the box says 'Plug & Play'.
>
>Now I'm having trouble getting Linux to see it (BIOS can see it as 'Simple
>COMM. Device' with IRQ 3).
>
>The error I get when pppd tries to talk to it is:
>
>tcgetattr: Input/output error(5)
>Exit.
>
>I also have /dev/modem symlinked to cua2, although that is probably bad
>because this is a PCI modem and doesn't point to a COM port (from what I
>understand about hardware...I could be wrong, I'm no expert) (so what should
>I do with /dev/modem ?)
>
>Does anyone know what I need to do to get Linux to see this new modem? What
>are some of the files that I may need to play with? I only found /etc/ppp/*
>stuff, but I don't think I need to touch anything there. Besides that I see
>how pppd and chat are invoked, but I don't think I can't do anything by
>messing with those.
>
>This is on Red Hat 5.1, kernel 2.0.35
>
>Any help would be very much appreciated!
>
>Thanks,
>
>Otis
>P.S.
>For everyone's info - NewCom, Inc.'s tech support is s-l-o-w :(
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Allen


(email addy; user ID portion has a numeral one in place of word
onespoiler, and of course, delete the bogus secondary domain of nospam.)
fight spam everywhere!!!

                            
                The irony is that Bill Gates claims to making a
                         stable operating system and
             Linus Torvalds claims to be trying to take over the world.
                
                 Linux; The Official OS of the New Millennium
                      
                          http://www.linuxlink.com

------------------------------

Crossposted-To: comp.os.linux,comp.os.linux.misc
Subject: Re: Can Linux use 36-bit Xeon addressing?
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 05 Mar 1999 19:25:33 -0500

Robert Krawitz <[EMAIL PROTECTED]> writes:

> 2 GB RAM is a satisfactory virtual address space for a single process
> for most purposes, but 1 or 2 GB RAM is not a satisfactory upper limit
> on RAM today.

but these are not `most purposes'.  the big ram user will almost
certainly need a shitload of ram for *one* process.  otherwise, you'd
just buy more machines and run one of the big (but not humongous)
processes on each.

e.g., a finite-element analysis requiring 7GB of memory for the matrix
math.  or a database application juggling a giant lump in memory.

-- 
                                           J o h a n  K u l l s t a m
                                           [[EMAIL PROTECTED]]
                                              Don't Fear the Penguin!

------------------------------

From: [EMAIL PROTECTED] (Allen)
Subject: Re: Xeon Processor...
Date: 5 Mar 1999 01:37:32 GMT

Based on what I know about hardware, I'd say skip the Xeon altogether, it's
price difference won't be justified by the subsequent performance gain.  Also,
I'd recommend starting with a dual P2 400, and putting the savings of the faster
CPU into bringing the RAM up to 512 Mb.  You can gain the benefits of the GX
chipset on many lower cost dual slot1 boards, eg. the Tyan 1836 DLUAN, and
Supermicro has one too.  The Tyan board can be had for less than $500, and
includes on-board 10/100 NIC, and UW SCSI.  I think the Supermicro version has
the U2W  SCSI,  check b4 you jump.

On Thu, 04 Mar 1999 21:26:18 GMT, John Burton <[EMAIL PROTECTED]> wrote:

>I'm planning on buying a low-end server machine to primarily do heavy
>duty number crunching (*BIG* atmospheric models) and generate large data
>files. I've been doing some research and it seems that the Pentium II
>Xeon processor running on an Intel SC450NX or AD450NX motherboard should
>be a screamer. But unfortunately my checkbook can't handle a full blown
>8 processor AD450NX system... My base requirements are:
>
> 450 Mhz Pentium II ??? processor (Initially single, but planning on SMP
>later)
> >256 MB memory
> 2x9 Gb SCSI LVD U2W disks (good swap & file I/O performance)
> 100 Base-T NIC
>
> I've found several options and am evaluating them, but I need some
>information...okay, relative to a Linux RedHat 5.2 base O/S with
>appropriate upgrades for the 2.2.2 (or greater) kernel:
>
> 1) is the ADAC A-466 Ultra2 SCSI Raid card supported under Linux?
> 2) is the Adaptec 7980 (and 7985) SCSI chipset *well* supported under
>Linux?
> 2) Can Linux make use of the 4-way interleaved memory access provided
>by the 450NX chipset?
> 3) Under Linux is there much performance difference between a Dual P-II
>on a 440BX motherboard and a Dual P-II Xeon on a 440GX motherboard
>(there is a *significant* price difference).
>
>I have a range of possibilities, but I need to justify it in terms of
>Price vs. Performance (i.e. how much faster will the large number
>crunching jobs be done, and will it be responsive in serving the files
>generated via NFS & Automount...
>
>Thoughts ? Suggestions? 
>
>John

Allen


(email addy; user ID portion has a numeral one in place of word
onespoiler, and of course, delete the bogus secondary domain of nospam.)
fight spam everywhere!!!

                            
                The irony is that Bill Gates claims to making a
                         stable operating system and
             Linus Torvalds claims to be trying to take over the world.
                
                 Linux; The Official OS of the New Millennium
                      
                          http://www.linuxlink.com

------------------------------

From: KenSiko <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux,comp.os.linux.questions
Subject: Re: 16bit mode in XWindows
Date: Fri, 05 Mar 1999 10:14:14 +0800

mike burrell wrote:

> In comp.os.linux Martin <[EMAIL PROTECTED]> wrote:
>
> | change this line to read :-
>
> |     serverargs="-bpp 16"
>
> | now the server will automatically start in 16 bpp mode
>
> this can be better done by editing the /etc/XF86Config and under the
> appropriate "Screen" section add the line:
>
>       DefaultColorDepth 16

While people are offering advice in this thread to the exact problem I
asked previously, I shall insert another query!! :)

I know my garbage cirrus logic gd5434 card supports 16 bit
colourdepth..Now, Its a crappy old compaq default card and I know is
supports 16 bit colour in windows 95 because I can have resolution of
800x600 at 16 bit. I have tried doing this with XF86Setup and when it
attempts to connect to the xserver it fails. I can only get resulutions of
8bit. While this is still ok for general use, I am too interested in
graphic apps, and the likes, to let it simply go. I've tired different
options to no avail, and the net offers links to obscure conf. files for
compaq laptops and the likes, but it seems my card (onboard bastard compaq
deal) deserves to be taken out and shot like the cripple it is...
Unfortunately Im stuck for a while..

I've tried starting the X-windows system with the options to make it 16
bit, but I get the same result.

Is there a generic SVGA setup that allows 16 bit at 800x600 for my card
type? I tried one generic option, and XF86Setup allowed me to specify it,
and let me complete the configuration - I think theres only 1 generic SVGA
option? in slackware at least, theyre all the same? - but when I attempted
to startx it dumped me back at the command line telling me that no such
modes were available. (800x600). Obviously windows can determine it, so am
I destined to be stuck at 8 bit because of old hardware in the linux world,
or is it possible?

At least, thus far, this is the biggest problem I face, and compared to the
ones I have so far overcome, is quite insignificant; just one of those
things I cant ignore!! :)

Cheers in advance,
Damian.



------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list (and comp.os.linux.hardware) via:

    Internet: [EMAIL PROTECTED]

Linux may be obtained via one of these FTP sites:
    ftp.funet.fi                                pub/Linux
    tsx-11.mit.edu                              pub/linux
    sunsite.unc.edu                             pub/Linux

End of Linux-Hardware Digest
******************************

Reply via email to