Linux-Hardware Digest #437, Volume #12 Wed, 8 Mar 00 21:13:07 EST
Contents:
Re: AGP + Linux = ? (Vladimir Florinski)
modem (in)compatibility.. (nrg2brn)
Re: Audio CD won't play under RH 6.1 ([EMAIL PROTECTED])
Re: VIA vs Intel chipsets - which is better? (tjasz)
Re: Impasse with 2 SCSI controllers, kernel mods required? (teri)
Re: 3c90x help ("Brett I. Holcomb")
Re: Digital Cameras and Linux (Douglas E. Mitton)
Re: AGP + Linux = ? (Dale Pontius)
Re: VIA vs Intel chipsets - which is better? ("Ron Reaugh")
----------------------------------------------------------------------------
From: Vladimir Florinski <[EMAIL PROTECTED]>
Subject: Re: AGP + Linux = ?
Date: Wed, 08 Mar 2000 18:10:20 -0700
ssr wrote:
>
> Where do u get the patch from?
>
http://matroxusers.com/driver/linux.html
http://utah-glx.sourceforge.net
--
Vladimir
------------------------------
Subject: modem (in)compatibility..
From: nrg2brn <[EMAIL PROTECTED]>
Date: Wed, 08 Mar 2000 17:29:28 -0800
Where do I find a comprehensive list of linux (corel-linux)
supported modems? Corels page was terrible.
I have a Supra max56 voice PCI
thanks.
please respond by email. I dont have access to WWW very often...
Dave
[EMAIL PROTECTED]
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Audio CD won't play under RH 6.1
Date: Thu, 09 Mar 2000 01:23:33 GMT
In article <[EMAIL PROTECTED]>,
Joe Glenn <[EMAIL PROTECTED]> wrote:
> Mine didn't work at first either.. but then I think it it started
working
> after I setup some sound card stuff in conf.modules. Id explain
exactly
> what I did but unless you have a neomagic256 I dont' think it'll help.
>
> if you do an 'lsmod' does it list sound card modules as being loaded?
>
Thanks Joe for the help. Yes, it does show sound card modules as being
loaded. I just switched from RH 6.1 to Mandrake 7.0, just for kicks.
But it still has the same problem. Sound Card is a Creative SB PCI 128
with surround sound. Oddly enough, the CD player in Mandrake (KDE) is
even able to bring up a list of the tracks. So, it recognizes that
something is in the drive, just won't give any sound. What types of
things should I put/change in conf.modules. I can't find any types of
reference on the web for this type of problem.
Thanks
Thomas
> [EMAIL PROTECTED] wrote:
>
> > I have mounted the CDROM and brought up the CD player in both Gnome
and
> > KDE. The counter goes up on the player but I get no sound. CD ROM
is a
> > Creative 48X. For those tech support people out there, yes the
volume is
> > turned up :)
> >
> > Works fine under Win98. Any thoughts on what the problem might be.
I am
> > somewhat new to Linux so I know enough to be dangerous.
> >
> > Thomas
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: tjasz <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.ibm.pc.hardware.chips,comp.sys.ibm.pc.hardware.systems
Subject: Re: VIA vs Intel chipsets - which is better?
Date: Wed, 08 Mar 2000 17:13:00 -0800
Reply-To: nospam@dontbother
this really gets old... I am a relative newby (and self engrandising
smartass!) how is it I've had a dozen or more VIA chipset boards and
assorted AMD processors and none of the problems you intellites
continue to have...perhaps its that I learned to set up VIA products
as you have learned to set up intel products...
On Wed, 8 Mar 2000 19:14:08 -0500, "Neil Davis"
<[EMAIL PROTECTED]> wrote:
I'm sorry to see this thread deteriorate so quickly into name-calling,
because there are some legitimate chipset and driver questions I'd
love to
see addressed. I've put together a number of VIA-based systems, but
recently I got fed up with them and have switched to the BX boards
instead.
One of the problems I've suffered with the VIA chipset is IRQ sharing.
It's
easy to end up with nicely configured systems that have more
peripherals
than available IRQ's, and my experience is that the VIA IRQ miniport
driver
doesn't allow IRQ sharing as well as the BX boards. I've seen VIA
boards
share IRQ's, but it's not the norm, and I haven't figured out how to
get it
to work as repeatably as the BX boards. For example, one of my
machines has
video, TV-tuner, video capture, SCSI, MODEM, and Soundblaster Live
(requires
2 IRQ's), USB, two IDE's, and they are all shared sociably on a BX
board
(one IRQ actually has 4 devices, and one IRQ is still listed as free).
So
question #1: is there something in the design of the IRQ hardware in
the
Intel chipset that allows it to work better with IRQ-sharing drivers,
or is
Intel just better at writing the IRQ-sharing driver, or is my
experience
with IRQ sharing not consistent with what others have seen?
The second problem I've had with VIA boards is poor support for
certain
devices using their busmastering drivers. For example, the Nakamichi
5x16
CD changer hangs up when you try to play audio CD's (using the drivers
from
VIA that were available last month). I also had problems with one of
the
Creative DVD players--lots of dropouts even when busmastering enabled,
although the Hitachi G2500 DVD player worked perfectly on the same
computer.
So question #2: is there something unique about the VIA IDE
hardware that
makes it difficult to get compatibility with more devices, or is this
just a
software maturity problem, and when will VIA finally get it right?
My recommendation to potential motherboard buyers has been to go with
the
lower-cost VIA boards if they aren't going to have lots of devices
that
require IRQ's or if they are going to stick with IDE devices that are
known
to work with the VIA drivers. The VIA boards are great for people who
don't
experiment much with different peripherals--I believe this is exactly
what
Michael Dell was referring to when he recently said: "We found the AMD
environment to be much more fragile ... than equivalent Intel
systems." I'm
not interested in starting a flame war--I'm curious whether others had
the
same negative experiences with the VIA chipset. Even more to the
point, I
am currently interested in buying an Athlon system, but I'm gun-shy
about
going with the KX-133 chipset. Any reports on how well it supports
IRQ
sharing?
Dean_Kent <[EMAIL PROTECTED]> wrote in message
news:#41yLVMi$GA.96@cpmsnbbsa02...
> Jim Cochrane <[EMAIL PROTECTED]> wrote in message
> news:8a4l62$[EMAIL PROTECTED]...
> > While calling a couple computer shops today to look into upgrading my
> > current system to a PIII motherboard, I came across an interesting
> > dilemna - essentially, two shops I talked to gave two different
> > opinions on chipsets available for Pentium III motherboards.
>
> Let me guess...
>
> >
> > I'm posting here to get y'all's opinions on these issues, but I think
> > it may also serve as an interesting (and possibly controversial) topic
> > of discussion. (Perhaps it has already been covered here and is old
> > hat; but unfortunately, my main machine is in the shop and I can't
> > access the web to look at dejanews with my 486.)
>
> Um, I'll bet one said VIA is buggy and the other said VIA is not-so-bad...
>
> >
> > The disagreement is on the quality of the non-Intel VIA chipset
> > versus the quality of the Intel chipsets. According to one shop, the
> > VIA chipset is much more buggy than the Intel chipsets (BX3 and I820, I
> > believe) and that this can potentially cause problems running a Linux
> > kernel (my intended OS). The fellow with this point of view stated
> > that the kernel has a lot of patches applied to work around bugs in the
> > VIA chipset. He acknowledged that the Intel chipsets had some bugs,
> > but not nearly as many as the VIA chipset.
> >
> > The fellow with the opposite opinion stated that this was false. He
> > essentially stated that there may be some bugs in both the VIA chipset
> > and the Intel chipsets, but that these bugs should not affect the linux
> > kernel and thus will not cause problems. (He also said he had
> > installed Linux on several such systems (VIA) and had not run into any
> > problems with respect to the chipset.)
>
> Yup. Sounds like one of the religious wars fought here in the past...
>
> >
> > Which of these opinions is correct? Or are they both partly right and
> > partly wrong? (With respect to my hardware upgrade, the questions, of
> > course, boils down to whether to purchase a VIA-based board, such as
> > Tyan, or an Intel-based board, such as a Supermicro.)
>
> Here is my opinion - VIA had some problems with AGP implementation (don't
> know all the details) with their SS7 chipset, but worked them out
> eventually, AFAIK. Unfortunately, once a reputation is gained, it is
near
> impossible to shake (just ask AMD). The current crop of Apollo Pro
> chipsets (133 and 133A) also had some AGP issues, but that was before they
> were released to the public (OEM samples only). These have been all but
> completely fixed. The only issue left is that the video transfer rates
are
> slightly slower than Intel's (BX and i820).
>
> When you consider that almost 50% of all Pentium II/III motherboards
shipped
> today to OEMs are VIA Apollo Pro based, it should tell you something...
>
> Now, here are your choices, IMO:
>
> Intel 440BX - tried and true. Currently fastest of all chipsets, overall.
> Limited to 2x AGP and UDMA/33 (though some manufacturers have 3rd party
IDE
> controllers to add UDMA/66). Officially supports only 66MHz and 100MHz
> FSB, and takes PC100 SDRAM (though many manufacturers implement 133MHz
FSB -
> some with 1/4 PCI divisor). If overclocking, AGP speed is 2/3 of CPU
speed,
> so that could cause problems.
>
> Intel i820 - almost as fast as the BX and has 4x AGP and UDMA/66 support.
> Supports 133MHz FSB. Unfortunately, it only accepts RDRAM in it's
'natural'
> state. To support SDRAM, it requires a 'Memory Translator Hub' chip,
which
> slows down perfomance and only officially supports 100MHz FSB. More
> expensive than BX solutions.
>
> VIA Apollo Pro133 or Pro133A - Almost as fast as BX (about the same as the
> i820, even at 100MHz FSB). Supports AGP 4x and UDMA/66. Also
officially
> supports 133MHz FSB, and has a better 'PCI/AGP divisor' scheme for
> overclockers. If the system is primarily for 3D games, it will be
slightly
> slower than a BX based board because the video transfer rate is a bit
> slower. Depending upon application, it could be 5% to 10% slower than BX
> based board.
>
> Can't speak to the Linux issue. I can't imagine why it would be a
problem,
> considering Intel licensed the P6 design to VIA so there shouldn't be any
> compatibility problems to speak of...
>
> >
> > [For those interested, I have also posted a question about another issue
> > I came across with the same two shops - see the subject line "PIII vs
PIII
> > E - which is faster?"]
>
> I'll render an opinion on that here as well...
>
> The Coppermine processors have a 256K full speed L2 cache that is 'wider'
> than the Klamath processors 512K 1/2 speed cache. It has a higher initial
> latency, but better overall throughput. Net result is that the Cu
> processors are faster. FSB is the same (memory to CPU), it is the cache
> speed that is different (BSB).
>
> Intel went to Socket 370 for Celeron early, because that was the 'low-end'
> processor, and Socket 370 saves bucks over the Slot 1 design. They are
now
> going to Socket 370 for *all* processors - and very soon, reportedly.
> PIII processors using Socket 370 have a lower voltage than the Celerons
> (1.6v vs. 2.0 v, I believe).
>
> >
> > [Apologies for any errors in terminology - as you can tell, I'm not a
> > hardware dude.]
>
> I'm sure that others will give their input, and correct any errors I may
> have made (as well as give any opinions that differ from mine)... :-)
>
> Regards,
> Dean
>
> > --
> > Jim Cochrane
> > [EMAIL PROTECTED]
>
>
------------------------------
From: [EMAIL PROTECTED] (teri)
Crossposted-To:
comp.os.linux.development.system,comp.os.linux.setup,alt.os.linux.caldera
Subject: Re: Impasse with 2 SCSI controllers, kernel mods required?
Date: Wed, 8 Mar 2000 20:26:14 EST
In article <8a5oge$q41$[EMAIL PROTECTED]>,
Marc SCHAEFER <[EMAIL PROTECTED]> wrote:
>In comp.os.linux.development.system teri <[EMAIL PROTECTED]> wrote:
>: Kernel recompile, this time with no 1542CF driver built-in. It is now
>: impossible to load the driver (Device or resource busy). I have read
>
>Any message issued by the dmesg command ? if it says something like
>`cannot allocate IRQ', reserve that IRQ in the PCI/PNP BIOS
>configuration as used by ISA/Legacy.
No. No messages at all related to the 1542CF or any failed loading
thereof. No "IRQ" messages either. I did a grep of all the
/var/log/messages* files as well as a careful examination and nothing
turned up. As I previously pointed out in the posting I referred to,
SCSISelect sees the 1542CF and the DMA test passes. There are no
IRQ, I/O or other resource conflict that I can see (the output of just
about all the /proc/* files was included in that posting)
My BIOS requires that PCI IRQs be reserved for PCI slots, given the
PCI cards I have. That's how I got the PCI cards to work, but there
is no such feature for the ISA bus. The other ISA card that has an
IRQ that's non-pnp (jumper) is the SMC ethernet card and I didn't have
to do anything in the BIOS for it to work perfectly. It's at IRQ 10.
The 1542CF is at IRQ 9 and nothing else is using it at the moment.
It used to be used by the PNP sound card without a problem. The sound
card is now using 15. In both cases it worked fine (it's being set up
by the commercial OSS driver)
One puzzling thing is that, in the case of both drivers being compiled
into the kernel, it would still insist on looking for the boot drive
on the wrong controller, even when that controller's BIOS is disabled.
Should it not ignore the controller whose BIOS is disabled for boot
purposes?
------------------------------
From: "Brett I. Holcomb" <[EMAIL PROTECTED]>
Subject: Re: 3c90x help
Date: Wed, 8 Mar 2000 18:57:12 -0600
My Caledera 2.3 found the 3C905B with no problem and it works so the card is
okay. You use the 3c59x driver as you did.
--
Brett I. Holcomb
[EMAIL PROTECTED]
Microsoft MVP
AKA Grunt<><
Remove R777 to reply
"Sergey Dashevskiy" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hello! Haven't been playing with Linux for a couple years, and already
> forgot enough to not be able to set up network card support :)
> I'm running Slackware 7, kernel 2.2.13 on a Dell box. Network card is
> 3Com 905B-TX.
> I couldn't find support for it in the list you get when compiling
> kernel, so I tried the 3c59x driver (I was told they are somewhat
> compatible). The module starts fine, no error messages (modprobe -v
> 3c59x). After that there's still no /dev/eth0, and the list of modules
> shows it as unused. No notice of the network card in /proc/devices or
> /proc/interrupts
>
> I tried looking on 3Com's site, got some driver for 3c90x. The version
> of the binary is not compatible with my kernel, and I can't recall how
> to compile and install one to save my life. Can anyone help please?
> Thanks! Sergey
------------------------------
From: [EMAIL PROTECTED] (Douglas E. Mitton)
Subject: Re: Digital Cameras and Linux
Reply-To: [EMAIL PROTECTED]
Date: Thu, 09 Mar 2000 01:49:34 GMT
Thank you VERY much for this link! I like this utility. GPhoto is
nice from a GUI point of view BUT command line utilities like this are
useful for un-attended or batch operation.
I was looking for something like this when I found gphoto, now I have
a chance at taking pictures from my web page! :-)
By the way I am using a Fuji DX-10 as well. Very good camera for its
price and intended use!
Thanks again!
[EMAIL PROTECTED] (Markus Wandel) wrote:
>In article <[EMAIL PROTECTED]>,
>Tom Rosso <[EMAIL PROTECTED]> wrote:
>
>>I have a Fujifilm MX-1200 digital camera that connects to the
>>back of my computer via a serial port. The software for this
>>camera has Windows 98/NT and Mac versions, but the authors didn't
>>have the forsight to include Linux software. Basically, from
>>what I can tell, it connects using some kind of Twain driver so
>>it can be accessed from Photoshop and Corel Draw and all of those
>>other wonderful expensive and buggy graphics programs. Does
>>anybody have any experience hooking up this camera, or any
>>Fujifilm MX-series camera, or any digital camera in general, to
>>Linux. I'm currently running Mandrake 7, which is compatable
>>(sort of) with RedHat. Any input would be appreciated. Thanks!
>
>I have a Fuji DX10 (predecessor to the MX1200) and I use this program:
>
> http://topo.math.u-psud.fr/~bousch/fujiplay.html
>
>It does exactly what a digital camera download program should do in
>my opinion:
------------------------------------------------
Doug Mitton - Brockville, Ontario, Canada
'City of the Thousand Islands'
EMail: [EMAIL PROTECTED]
http://www.cybertap.com/dmitton
Other: mitton.dyn.ml.org
SPAM Reduction: Remove "x." from my domain.
------------------------------------------------
------------------------------
From: [EMAIL PROTECTED] (Dale Pontius)
Subject: Re: AGP + Linux = ?
Date: Wed, 8 Mar 2000 19:53:34 -0500
In article <[EMAIL PROTECTED]>,
mircea <[EMAIL PROTECTED]> writes:
> anthony wrote:
>>
>> Is there any kernel support for the the AGP port such as
>> filling in the GART / memory management / chipset init etc?
>>
>> Grepping with agp on kernel 2.2.5.15 doesn't show anything.
>>
>
> http://glx.on.openprojects.net
> You may also want to try a more recent kernel than 2.2.5!
>
This stuff has moved to http://utah-glx.sourceforge.net
There is also some degree of merge/overlap between this and
the Direct Rendering Infrastructure, also at the SourceForge
at http://dri.sourceforge.net
Using AGP involves the agpgart or newgart kernel patch, and
there is a kernel patch for DRI that has already been added
to the 2.3 kernel tree. The Utah-GLX work will run on the
current XFree86 3.3.5+ release. I believe the DRI work needs
to be run on the 3.9.17+ work, or just wait for XFree86 4.0
later this month.
Dale Pontius
------------------------------
From: "Ron Reaugh" <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.ibm.pc.hardware.chips,comp.sys.ibm.pc.hardware.systems
Subject: Re: VIA vs Intel chipsets - which is better?
Date: Thu, 09 Mar 2000 02:05:14 GMT
Neil Davis wrote in message <8a6qbt$[EMAIL PROTECTED]>...
>I'm sorry to see this thread deteriorate so quickly into name-calling,
>because there are some legitimate chipset and driver questions I'd love to
>see addressed. I've put together a number of VIA-based systems, but
>recently I got fed up with them and have switched to the BX boards instead.
>One of the problems I've suffered with the VIA chipset is IRQ sharing.
Right, I forgot that one.
> It's
>easy to end up with nicely configured systems that have more peripherals
>than available IRQ's, and my experience is that the VIA IRQ miniport driver
>doesn't allow IRQ sharing as well as the BX boards. I've seen VIA boards
>share IRQ's, but it's not the norm, and I haven't figured out how to get it
>to work as repeatably as the BX boards. For example, one of my machines
has
>video, TV-tuner, video capture, SCSI, MODEM, and Soundblaster Live
(requires
>2 IRQ's), USB, two IDE's, and they are all shared sociably on a BX board
>(one IRQ actually has 4 devices, and one IRQ is still listed as free). So
>question #1: is there something in the design of the IRQ hardware in the
>Intel chipset that allows it to work better with IRQ-sharing drivers, or is
>Intel just better at writing the IRQ-sharing driver, or is my experience
>with IRQ sharing not consistent with what others have seen?
>
>The second problem I've had with VIA boards is poor support for certain
>devices using their busmastering drivers.
That's a big one.
> For example, the Nakamichi 5x16
>CD changer hangs up when you try to play audio CD's (using the drivers from
>VIA that were available last month). I also had problems with one of the
>Creative DVD players--lots of dropouts even when busmastering enabled,
There are endless reports like this in numerous NGs. My CDR[W] wont work in
DMA mode on my VIA chipset mobo. Shortly a guy with the exact same
CDR[W]pipes up my works fine on my Intel chipset mobo. When one tries to
summarize these experiences as I have here then one is immediately pounced
upon by a legion of VIA shills.
>although the Hitachi G2500 DVD player worked perfectly on the same
computer.
>So question #2: is there something unique about the VIA IDE hardware
that
>makes it difficult to get compatibility with more devices, or is this just
a
>software maturity problem, and when will VIA finally get it right?
Not clear. They've had a fair time to get it right already.
>My recommendation to potential motherboard buyers has been to go with the
>lower-cost VIA boards if they aren't going to have lots of devices that
>require IRQ's or if they are going to stick with IDE devices that are known
>to work with the VIA drivers.
If you want to use VIA then make all non-HD gadgets SCSI like they should be
in the first place. This avoids the VIA busmastering EIDE driver problems
because usually the VIA works with one HD alone on each of the two EIDE
controllers.
> The VIA boards are great for people who don't
>experiment much with different peripherals--I believe this is exactly what
>Michael Dell was referring to when he recently said: "We found the AMD
>environment to be much more fragile ... than equivalent Intel systems."
I'm
>not interested in starting a flame war--I'm curious whether others had the
>same negative experiences with the VIA chipset. Even more to the point, I
>am currently interested in buying an Athlon system, but I'm gun-shy about
>going with the KX-133 chipset. Any reports on how well it supports IRQ
>sharing?
>
>
>Dean_Kent <[EMAIL PROTECTED]> wrote in message
>news:#41yLVMi$GA.96@cpmsnbbsa02...
>> Jim Cochrane <[EMAIL PROTECTED]> wrote in message
>> news:8a4l62$[EMAIL PROTECTED]...
>> > While calling a couple computer shops today to look into upgrading my
>> > current system to a PIII motherboard, I came across an interesting
>> > dilemna - essentially, two shops I talked to gave two different
>> > opinions on chipsets available for Pentium III motherboards.
>>
>> Let me guess...
>>
>> >
>> > I'm posting here to get y'all's opinions on these issues, but I think
>> > it may also serve as an interesting (and possibly controversial) topic
>> > of discussion. (Perhaps it has already been covered here and is old
>> > hat; but unfortunately, my main machine is in the shop and I can't
>> > access the web to look at dejanews with my 486.)
>>
>> Um, I'll bet one said VIA is buggy and the other said VIA is
not-so-bad...
>>
>> >
>> > The disagreement is on the quality of the non-Intel VIA chipset
>> > versus the quality of the Intel chipsets. According to one shop, the
>> > VIA chipset is much more buggy than the Intel chipsets (BX3 and I820, I
>> > believe) and that this can potentially cause problems running a Linux
>> > kernel (my intended OS). The fellow with this point of view stated
>> > that the kernel has a lot of patches applied to work around bugs in the
>> > VIA chipset. He acknowledged that the Intel chipsets had some bugs,
>> > but not nearly as many as the VIA chipset.
>> >
>> > The fellow with the opposite opinion stated that this was false. He
>> > essentially stated that there may be some bugs in both the VIA chipset
>> > and the Intel chipsets, but that these bugs should not affect the linux
>> > kernel and thus will not cause problems. (He also said he had
>> > installed Linux on several such systems (VIA) and had not run into any
>> > problems with respect to the chipset.)
>>
>> Yup. Sounds like one of the religious wars fought here in the past...
>>
>> >
>> > Which of these opinions is correct? Or are they both partly right and
>> > partly wrong? (With respect to my hardware upgrade, the questions, of
>> > course, boils down to whether to purchase a VIA-based board, such as
>> > Tyan, or an Intel-based board, such as a Supermicro.)
>>
>> Here is my opinion - VIA had some problems with AGP implementation (don't
>> know all the details) with their SS7 chipset, but worked them out
>> eventually, AFAIK. Unfortunately, once a reputation is gained, it is
>near
>> impossible to shake (just ask AMD). The current crop of Apollo Pro
>> chipsets (133 and 133A) also had some AGP issues, but that was before
they
>> were released to the public (OEM samples only). These have been all but
>> completely fixed. The only issue left is that the video transfer rates
>are
>> slightly slower than Intel's (BX and i820).
>>
>> When you consider that almost 50% of all Pentium II/III motherboards
>shipped
>> today to OEMs are VIA Apollo Pro based, it should tell you something...
>>
>> Now, here are your choices, IMO:
>>
>> Intel 440BX - tried and true. Currently fastest of all chipsets,
overall.
>> Limited to 2x AGP and UDMA/33 (though some manufacturers have 3rd party
>IDE
>> controllers to add UDMA/66). Officially supports only 66MHz and 100MHz
>> FSB, and takes PC100 SDRAM (though many manufacturers implement 133MHz
>FSB -
>> some with 1/4 PCI divisor). If overclocking, AGP speed is 2/3 of CPU
>speed,
>> so that could cause problems.
>>
>> Intel i820 - almost as fast as the BX and has 4x AGP and UDMA/66 support.
>> Supports 133MHz FSB. Unfortunately, it only accepts RDRAM in it's
>'natural'
>> state. To support SDRAM, it requires a 'Memory Translator Hub' chip,
>which
>> slows down perfomance and only officially supports 100MHz FSB. More
>> expensive than BX solutions.
>>
>> VIA Apollo Pro133 or Pro133A - Almost as fast as BX (about the same as
the
>> i820, even at 100MHz FSB). Supports AGP 4x and UDMA/66. Also
>officially
>> supports 133MHz FSB, and has a better 'PCI/AGP divisor' scheme for
>> overclockers. If the system is primarily for 3D games, it will be
>slightly
>> slower than a BX based board because the video transfer rate is a bit
>> slower. Depending upon application, it could be 5% to 10% slower than
BX
>> based board.
>>
>> Can't speak to the Linux issue. I can't imagine why it would be a
>problem,
>> considering Intel licensed the P6 design to VIA so there shouldn't be any
>> compatibility problems to speak of...
>>
>> >
>> > [For those interested, I have also posted a question about another
issue
>> > I came across with the same two shops - see the subject line "PIII vs
>PIII
>> > E - which is faster?"]
>>
>> I'll render an opinion on that here as well...
>>
>> The Coppermine processors have a 256K full speed L2 cache that is 'wider'
>> than the Klamath processors 512K 1/2 speed cache. It has a higher
initial
>> latency, but better overall throughput. Net result is that the Cu
>> processors are faster. FSB is the same (memory to CPU), it is the cache
>> speed that is different (BSB).
>>
>> Intel went to Socket 370 for Celeron early, because that was the
'low-end'
>> processor, and Socket 370 saves bucks over the Slot 1 design. They are
>now
>> going to Socket 370 for *all* processors - and very soon, reportedly.
>> PIII processors using Socket 370 have a lower voltage than the Celerons
>> (1.6v vs. 2.0 v, I believe).
>>
>> >
>> > [Apologies for any errors in terminology - as you can tell, I'm not a
>> > hardware dude.]
>>
>> I'm sure that others will give their input, and correct any errors I may
>> have made (as well as give any opinions that differ from mine)... :-)
------------------------------
** 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
******************************
