On Wednesday 19 Mar 2008, linuxers-request@mm.glug-bom.org wrote:
Message: 4 Date: Wed, 19 Mar 2008 01:25:36 +0530 From: "Dinesh Joshi" dinesh.a.joshi@gmail.com Subject: Re: [ILUG-BOM] [OT] Avoid Intel motherboards
On Tue, Mar 18, 2008 at 2:25 PM, Rony gnulinuxist@gmail.com wrote:
If anyone of you is planning to buy a system or a new motherboard then avoid Intel original ones like plague. They take more than a month to simply pick up boards in warranty and their communication channels are pathetic. My colleagues and I have some warranty boards lying with us for more than a month and they have yet to be picked up by Intel. Their service is too bad.
Well, atleast Intel has a service. For GNU/Linux users, AMD Boards should be ideally avoided like plague ;) Anyway, must be a temporary thing. It wasn't that bad about a year ago...
Any particular brand mobos for the AMD cpus?
The OP identified Intel manufactured mobos, not all manufacturers of mobos for the Intel family.
-- Arun Khan
On Wed, Mar 19, 2008 at 5:19 PM, Arun Khan knura@yahoo.com wrote:
Any particular brand mobos for the AMD cpus?
Well we have HCL machines at our lab. High end AMD64 X2 CPUs. Not sure the brand of the motherboard, it doesn't have drivers. We struggled to get DRI to work properly. As opposed to this my experience with every single Intel motherboard ( lowend or highend ) has been that it has worked out of the box except the last Intel board DG965RYCK. The fix for which was rolled out pretty quickly.
On Thursday 20 March 2008 01:27 pm, Dinesh Joshi wrote:
On Wed, Mar 19, 2008 at 5:19 PM, Arun Khan knura@yahoo.com wrote:
Any particular brand mobos for the AMD cpus?
Well we have HCL machines at our lab. > High end AMD64 X2 CPUs. Not sure the brand of the motherboard, it doesn't have drivers. We struggled to get DRI to work properly.
So it is HCL not AMD. ALWAYS if you want good service get a small vendor. The big guys are full of hype n hotair and outsource everything to the small guys minus the profit. All the money you pay is just to cover jazzy ads about cows and bulls on BBC. And if you are wise get the mobos and build the boxes your self.
lspci -v ?
AMD is any day a better bet as far as drivers go. They have opened the specs to the cpu, chipset and the 3d graphics engine as well. Only a matter of time before you have full 3d support on all AMD chipsets.
As opposed to this my experience with every single Intel motherboard ( lowend or highend ) has been that it has worked out of the box except the last Intel board DG965RYCK. The fix for which was rolled out pretty quickly.
Compare the performance specs. Intel SUCKS in the same price band. And the ad thingy holds for Intel too.
Looks like a good rule of thumb would be to avoid stuff that is advertised. The more the ads the farther you run.
My ASUS m2nMX-se are working rock solid and cold for more than a year.
On Thu, Mar 20, 2008 at 2:18 PM, jtd jtd@mtnl.net.in wrote:
<snip>
My ASUS m2nMX-se are working rock solid and cold for more than a year.
<snip>
As are our ASUS M2N-VM DX DVI boards for AMD X2.
On Thu, Mar 20, 2008 at 2:18 PM, jtd jtd@mtnl.net.in wrote:
So it is HCL not AMD. ALWAYS if you want good service get a small vendor. The big guys are full of hype n hotair and outsource everything to the small guys minus the profit. All the money you pay is just to cover jazzy ads about cows and bulls on BBC. And if you are wise get the mobos and build the boxes your self.
Right blame HCL for the lack of drivers. The driver issue we face is simply because the open source drivers dont work well and the proprietary NVidia ( now merged with AMD ) work like _ _ _ _.
lspci -v ?
00:00.0 Host bridge: ATI Technologies Inc RS690 Host Bridge Subsystem: Giga-byte Technology Unknown device 5000 Flags: bus master, 66MHz, medium devsel, latency 32
00:01.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (Internal gfx) (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 99 Bus: primary=00, secondary=01, subordinate=01, sec-latency=68 I/O behind bridge: 0000e000-0000efff Memory behind bridge: fde00000-fdffffff Prefetchable memory behind bridge: 00000000d8000000-00000000dfffffff Capabilities: [44] HyperTransport: MSI Mapping Capabilities: [b0] Subsystem: ATI Technologies Inc RS690 PCI to PCI Bridge (Internal gfx)
00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA (prog-if 01 [AHCI 1.0]) Subsystem: Giga-byte Technology Unknown device b002 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 22 I/O ports at ff00 [size=8] I/O ports at fe00 [size=4] I/O ports at fd00 [size=8] I/O ports at fc00 [size=4] I/O ports at fb00 [size=16] Memory at fe02f000 (32-bit, non-prefetchable) [size=1K] Capabilities: [60] Power Management version 2
00:13.0 USB Controller: ATI Technologies Inc SB600 USB (OHCI0) (prog-if 10 [OHCI]) Subsystem: Giga-byte Technology Unknown device 5004 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16 Memory at fe02e000 (32-bit, non-prefetchable) [size=4K]
00:13.1 USB Controller: ATI Technologies Inc SB600 USB (OHCI1) (prog-if 10 [OHCI]) Subsystem: Giga-byte Technology Unknown device 5004 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 17 Memory at fe02d000 (32-bit, non-prefetchable) [size=4K]
00:13.2 USB Controller: ATI Technologies Inc SB600 USB (OHCI2) (prog-if 10 [OHCI]) Subsystem: Giga-byte Technology Unknown device 5004 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 18 Memory at fe02c000 (32-bit, non-prefetchable) [size=4K]
00:13.3 USB Controller: ATI Technologies Inc SB600 USB (OHCI3) (prog-if 10 [OHCI]) Subsystem: Giga-byte Technology Unknown device 5004 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 17 Memory at fe02b000 (32-bit, non-prefetchable) [size=4K]
00:13.4 USB Controller: ATI Technologies Inc SB600 USB (OHCI4) (prog-if 10 [OHCI]) Subsystem: Giga-byte Technology Unknown device 5004 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 18 Memory at fe02a000 (32-bit, non-prefetchable) [size=4K]
00:13.5 USB Controller: ATI Technologies Inc SB600 USB Controller (EHCI) (prog-if 20 [EHCI]) Subsystem: Giga-byte Technology Unknown device 5004 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 19 Memory at fe029000 (32-bit, non-prefetchable) [size=256] Capabilities: [c0] Power Management version 2 Capabilities: [e4] Debug port
00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 14) Subsystem: Giga-byte Technology Unknown device 4385 Flags: 66MHz, medium devsel I/O ports at 0b00 [size=16] Capabilities: [b0] HyperTransport: MSI Mapping
00:14.1 IDE interface: ATI Technologies Inc SB600 IDE (prog-if 8a [Master SecP PriP]) Subsystem: Giga-byte Technology Unknown device 5002 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16 I/O ports at 01f0 [size=8] I/O ports at 03f4 [size=1] I/O ports at 0170 [size=8] I/O ports at 0374 [size=1] I/O ports at f900 [size=16]
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia Subsystem: Giga-byte Technology Unknown device a002 Flags: bus master, slow devsel, latency 32, IRQ 16 Memory at fe024000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2
00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge Subsystem: Giga-byte Technology Unknown device 5001 Flags: bus master, 66MHz, medium devsel, latency 0
00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge (prog-if 01 [Subtractive decode]) Flags: bus master, VGA palette snoop, 66MHz, medium devsel, latency 64 Bus: primary=00, secondary=02, subordinate=02, sec-latency=64 I/O behind bridge: 0000d000-0000dfff Memory behind bridge: fdd00000-fddfffff Prefetchable memory behind bridge: fdc00000-fdcfffff
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration Flags: fast devsel Capabilities: [80] HyperTransport: Host or Secondary Interface
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map Flags: fast devsel
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller Flags: fast devsel
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control Flags: fast devsel Capabilities: [f0] #0f [0010]
01:05.0 VGA compatible controller: ATI Technologies Inc Radeon X1200 Series (prog-if 00 [VGA]) Subsystem: Giga-byte Technology Unknown device d000 Flags: bus master, fast devsel, latency 32, IRQ 18 Memory at d8000000 (64-bit, prefetchable) [size=128M] Memory at fdff0000 (64-bit, non-prefetchable) [size=64K] I/O ports at ee00 [size=256] Memory at fde00000 (32-bit, non-prefetchable) [size=1M] Capabilities: [50] Power Management version 2 Capabilities: [80] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
02:0f.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10) Subsystem: Giga-byte Technology Unknown device e000 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 23 I/O ports at de00 [size=256] Memory at fddff000 (32-bit, non-prefetchable) [size=256] [virtual] Expansion ROM at fdc00000 [disabled] [size=128K] Capabilities: [dc] Power Management version 2
AMD is any day a better bet as far as drivers go. They have opened the specs to the cpu, chipset and the 3d graphics engine as well. Only a matter of time before you have full 3d support on all AMD chipsets.
lets see.
Compare the performance specs. Intel SUCKS in the same price band. And the ad thingy holds for Intel too.
Not at all. Compare the prices of Core2Duo CPUs and motherboards with AMD. They are competitive.
On Thu, Mar 20, 2008 at 2:45 PM, Dinesh Joshi dinesh.a.joshi@gmail.com wrote:
Right blame HCL for the lack of drivers. The driver issue we face is simply because the open source drivers dont work well and the proprietary NVidia ( now merged with AMD ) work like _ _ _ _.
This system doesn't seem to have NVidia graphics card. Its an ATI Radeon X1200.
Dinesh Joshi wrote:
On Thu, Mar 20, 2008 at 2:18 PM, jtd jtd@mtnl.net.in wrote:
So it is HCL not AMD. ALWAYS if you want good service get a small vendor. The big guys are full of hype n hotair and outsource everything to the small guys minus the profit. All the money you pay is just to cover jazzy ads about cows and bulls on BBC. And if you are wise get the mobos and build the boxes your self.
Right blame HCL for the lack of drivers. The driver issue we face is simply because the open source drivers dont work well and the proprietary NVidia ( now merged with AMD ) work like _ _ _ _.
We are diverting from the thread. The issue is about service support provided by motherboard manufacturers in case of a breakdown. Anyway, GNU compatibility is not just dependent on the chipset but also the BIOS of the motherboard. That is why 2 Intel 845 boards of different types will not have the same result in GNU. I faced this problem when trying out GLVA, GVSR etc. One of them ?? would not give screen resol. beyond 640x480 when installed out of the box. Similarly with AMD boards, it varies from case to case and on chipsets.
About 2 years ago I had supplied 2 systems with AMD Dual Core 4200+ and Asus A2NSLi(?) and just for kicks I tried out an Ubuntu 5.10 or 6.06 live CD and got a screen resol of 1900xSomething on the 19" CRT monitor. The display card was an add-on nVidia quadro fx with 512 MB RAM.
Last year in December I had a tough time installing GNU on an AMD machine with VIA chipsets on an Asus board. Some of my CDs would not even get detected as present. This even after trying another CD drive. Later it would not allow me to make a partition bigger than 10 to 12 GB. Finally Kubuntu 7.04 was installed and it is working fine with Samba for LAN browsing and Windows printer sharing.
On Thursday 20 March 2008 08:33 pm, Rony wrote:
Right blame HCL for the lack of drivers. The driver issue we face is simply because the open source drivers dont work well and the proprietary NVidia ( now merged with AMD ) work like _ _ _ _.
Anyway, GNU compatibility is not just dependent on the chipset but also the BIOS of the motherboard.
No. Linux or X does not depend on the bios at all.
That is why 2 Intel 845 boards of different types will not have the same result in GNU. I faced this problem when trying out GLVA, GVSR etc. One of them ?? would not give screen resol. beyond 640x480 when installed out of the box. Similarly with AMD boards, it varies from case to case and on chipsets.
The "same" chipsets are not quite the same from 1 rev to the next. Some of them have bugs which will surface now and then.
On 20-Mar-08, at 9:42 PM, jtd wrote:
Anyway, GNU compatibility is not just dependent on the chipset but also the BIOS of the motherboard.
No. Linux or X does not depend on the bios at all.
he is not talking about Linux - GNU == Hurd
Kenneth Gonsalves wrote:
On 20-Mar-08, at 9:42 PM, jtd wrote:
Anyway, GNU compatibility is not just dependent on the chipset but also the BIOS of the motherboard.
No. Linux or X does not depend on the bios at all.
he is not talking about Linux - GNU == Hurd
No.
On 23-Mar-08, at 8:29 PM, Rony wrote:
he is not talking about Linux - GNU == Hurd
No.
you mean you are running without a kernel?
On Mon, Mar 24, 2008 at 7:59 AM, Kenneth Gonsalves lawgon@au-kbc.org wrote:
you mean you are running without a kernel?
I know this is a sensitive topic but can we focus on the discussion and _not_ on the terminology? You and I ( and everyone on this list knows ) that:
Rony's GNU == GNU/Linux My Linux == GNU/Linux Anybody else's Linux == GNU/Linux
So it means the _same_ thing. Lets not take this thread more OT, shall we?
Oh yes and I'm a hypocrite to take this thread OT in the first place ;-)
Rony, Linux depends very little on the BIOSes to tell it what hardware it has. AFAIK it depends on the BIOS only for bootstrapping. Everything else is taken care by the kernel. And yes, there are a lot of retarded BIOSes compiled using the MS compiler but then we can't help it. ACPI support sucks on most machines because of such BIOSes but then we have to work around it and thats exactly what Linux attempts to do.
On Mon, Mar 24, 2008 at 12:16 PM, Dinesh Joshi dinesh.a.joshi@gmail.com wrote:
On Mon, Mar 24, 2008 at 7:59 AM, Kenneth Gonsalves lawgon@au-kbc.org wrote:
you mean you are running without a kernel?
of retarded BIOSes compiled using the MS compiler but then we can't help it. ACPI support sucks on most machines because of such BIOSes
Even BIOSes compiled with MS compilers. yyaaack! Can someone point to a list of vendors who do that.. i would avoid them _As Far and Long As Possible_
On 3/24/08, km km@eficacy.com wrote:
Even BIOSes compiled with MS compilers. yyaaack! Can someone point to a list of vendors who do that.. i would avoid them _As Far and Long As Possible_
I believe this would tell you if your BIOS was compiled using a Microsoft compiler: dmesg | grep MSFT
You should get some output like: ACPI: FACP 3E6FC000, 0074 (r1 INTEL DG965RY 330 MSFT 1000013) ACPI: DSDT 3E6F8000, 3EDA (r1 INTEL DG965RY 330 MSFT 1000013) ACPI: APIC 3E6F7000, 0078 (r1 INTEL DG965RY 330 MSFT 1000013) ACPI: WDDT 3E6F6000, 0040 (r1 INTEL DG965RY 330 MSFT 1000013) ACPI: MCFG 3E6F5000, 003C (r1 INTEL DG965RY 330 MSFT 1000013) ACPI: ASF! 3E6F4000, 00A6 (r32 INTEL DG965RY 330 MSFT 1000013) ACPI: SSDT 3E6F3000, 01BC (r1 INTEL CpuPm 330 MSFT 1000013) ACPI: SSDT 3E6F2000, 0175 (r1 INTEL Cpu0Ist 330 MSFT 1000013) ACPI: SSDT 3E6AB000, 0175 (r1 INTEL Cpu1Ist 330 MSFT 1000013) ACPI: SSDT 3E6AA000, 0175 (r1 INTEL Cpu2Ist 330 MSFT 1000013) ACPI: SSDT 3E6A9000, 0175 (r1 INTEL Cpu3Ist 330 MSFT 1000013)
Yes, my BIOS was also compiled on a Microsoft Compiler! :/
Dinesh Joshi wrote:
Rony, Linux depends very little on the BIOSes to tell it what hardware it has. AFAIK it depends on the BIOS only for bootstrapping. Everything else is taken care by the kernel. And yes, there are a lot of retarded BIOSes compiled using the MS compiler but then we can't help it. ACPI support sucks on most machines because of such BIOSes but then we have to work around it and thats exactly what Linux attempts to do.
We work around it but is the BIOS not the culprit in such cases? I am not saying that GNU won't load on these machines. Its just a painful experience on such boards. ;)
On 24-Mar-08, at 7:47 PM, Rony wrote:
We work around it but is the BIOS not the culprit in such cases? I am not saying that GNU won't load on these machines.
GNU will not load on *any* machine - you need a kernel for that
jtd wrote:
On Thursday 20 March 2008 08:33 pm, Rony wrote:
Anyway, GNU compatibility is not just dependent on the chipset but also the BIOS of the motherboard.
No. Linux or X does not depend on the bios at all.
But what about lousy bioses ( that are M$ friendly but not GNU ) that add pain to the installation and device detection?
That is why 2 Intel 845 boards of different types will not have the same result in GNU. I faced this problem when trying out GLVA, GVSR etc. One of them ?? would not give screen resol. beyond 640x480 when installed out of the box. Similarly with AMD boards, it varies from case to case and on chipsets.
The "same" chipsets are not quite the same from 1 rev to the next. Some of them have bugs which will surface now and then.
Hmm!
On 3/20/08, Dinesh Joshi dinesh.a.joshi@gmail.com wrote:
As opposed to this my experience with every single Intel motherboard ( lowend or highend ) has been that it has worked out of the box except the last Intel board DG965RYCK. The fix for which was rolled out pretty quickly.
Didn't face D101GGC or D102GGC? AFAICR, these 2 had been PITA for quite a while.
-
Arun Khan -
Dinesh Joshi -
jtd -
Kenneth Gonsalves -
km -
Mehul Ved -
Rony -
Yesudeep