Re: Intel (s775) Johannesburg DQ35JOE mATX
On Fri, Jan 25, 2008 at 08:20:32AM -0500, Justin Piszcz wrote: > I use a 965 and p35 boards. > > The problem with the cache is annoying but just append mem=8832MB (for an > 8GIB) config and it solves the issue (with the 965)-- no issue with the > p35/gigabyte I have. gigabyte was very quick to fix the BIOS bug when someone emailed them about it. So yes a gigabyte board would not have a problem anymore. Some companies didn't ever have a problem in the first place that I know of (I don't recall ever seeing asus mentioned as having this problem, but asus does tend to rewrite most of the bios themselves, so they probably cought it and fixed it before release). I can't tell if my new board has any such issues (although I doubt it) since I only have 2GB ram on it. It uses the P35 chipset as well. The Q6600 is very very fast though. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intel (s775) Johannesburg DQ35JOE mATX
On Thu, Jan 24, 2008 at 10:21:56PM +0100, Gudjon I. Gudjonsson wrote: > The salesman knew this problem but said it was a problem with the 965 chip > but was solved with the Q35 chip. I hope he is right. There was nothing wrong with the chip. It was an error in how the BIOS configured the system. Companies other than intel managed to fix the problem within hours of being notified, while intel claimed (at least for a while) that what they were doing was correct and that there was nothing wrong. If you leave part of the memory flagged as not cacheable, you are going to make that part of memory very slow, and that's what intel's bios was doing. As soon as you change the MTRR entries to make all ram cacheable the performance returns to normal. On one intel board it even used to work and then a bios upgrade fixed it, and for the next 6+ months people were complaining (and usually going back to the old bios just to make their systems usable again). If you want quality motherboards and service, intel is NOT the company to get it from. If you want quality chips then intel is a perfectly good choice. It's somewhat like ATI. Nice hardware, shame about the software parts. > About the kernel, I most often end up installing Debian unstable and then > I wait for it to become stable if there are no problems. But on my main > computer I happily use unstable and experimental. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intel (s775) Johannesburg DQ35JOE mATX
On Thu, 24 Jan 2008, Gudjon I. Gudjonsson wrote: Thanks Lennart (and others) for a very through explanation. Sorry for abusing your time but I am going to buy a computer with the following ingredients. I am quite worried that I might have to wait for half a year for support of some of the chips so I decided to ask first if someone has used this (with good or bad experience): Motherboard: Intel (s775) Johannesburg DQ35JOE mATX I have only used a few Intel boards myself, but I wouldn't buy one. I only buy Asus boards. There has been a lot of trouble for people with more than 3GB ram and getting the MTRR cache setup right on intel boards in the last year, and it has taken a lot of pushing to even get intel to admit they screwed up their bios, while Gigabyte and Asus had a new bios within days of being notified of the mistake in intel's reference code. Not what I would consider a well supported board. Most affected users were windows 64bit users who got a very very slow system if they had more than 3GB ram installed, and linux gets the same slow performance since the top of ram is not cached and hence very slow. The salesman knew this problem but said it was a problem with the 965 chip but was solved with the Q35 chip. I hope he is right. About the kernel, I most often end up installing Debian unstable and then I wait for it to become stable if there are no problems. But on my main computer I happily use unstable and experimental. Cheers Gudjon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] I use a 965 and p35 boards. The problem with the cache is annoying but just append mem=8832MB (for an 8GIB) config and it solves the issue (with the 965)-- no issue with the p35/gigabyte I have. Justin. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intel (s775) Johannesburg DQ35JOE mATX
Thanks Lennart (and others) for a very through explanation. >>Sorry for abusing your time but I am going to buy a computer with the >> following ingredients. I am quite worried that I might have to wait for >> half a year for support of some of the chips so I decided to ask first >> if someone has used this (with good or bad experience): >> >> Motherboard: Intel (s775) Johannesburg DQ35JOE mATX > > I have only used a few Intel boards myself, but I wouldn't buy one. I > only buy Asus boards. There has been a lot of trouble for people with > more than 3GB ram and getting the MTRR cache setup right on intel boards > in the last year, and it has taken a lot of pushing to even get intel to > admit they screwed up their bios, while Gigabyte and Asus had a new bios > within days of being notified of the mistake in intel's reference code. > Not what I would consider a well supported board. Most affected users > were windows 64bit users who got a very very slow system if they had > more than 3GB ram installed, and linux gets the same slow performance > since the top of ram is not cached and hence very slow. The salesman knew this problem but said it was a problem with the 965 chip but was solved with the Q35 chip. I hope he is right. About the kernel, I most often end up installing Debian unstable and then I wait for it to become stable if there are no problems. But on my main computer I happily use unstable and experimental. Cheers Gudjon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intel (s775) Johannesburg DQ35JOE mATX
On 01/23/08 08:39:44PM +0100, Jonas Meurer wrote: > On 23/01/2008 Steve Dobson wrote: > > You don't need a backport of the kernel packages. They are stand alone > > pieces of software that nothing depends upon and depend on nothing > > themselves (in the packaging sense; I know the system needs a kernel to > > run). You can just down load the kernel packages of your choice. > > Even though unstable kernel packages may work in etch, your statement is > not true in general. Newer kernel needs newer udev at least, and I guess > that some minimal glibc version is required as well. > Actually the userland requirements have been pretty lax lately. According to the latest upstream kernel's git udev 081 is required and etch is already at 105. And just about any glibc should work because both the kernel and glibc have lots of compatibility to ensure interoperability. Hell there's not even a glibc version listed in the Changes file. Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intel (s775) Johannesburg DQ35JOE mATX
On 23/01/2008 Steve Dobson wrote: > You don't need a backport of the kernel packages. They are stand alone > pieces of software that nothing depends upon and depend on nothing > themselves (in the packaging sense; I know the system needs a kernel to > run). You can just down load the kernel packages of your choice. Even though unstable kernel packages may work in etch, your statement is not true in general. Newer kernel needs newer udev at least, and I guess that some minimal glibc version is required as well. greetings, jonas signature.asc Description: Digital signature
Re: Intel (s775) Johannesburg DQ35JOE mATX
On Wed, Jan 23, 2008 at 06:15:56PM +, Steve Dobson wrote: > You don't need a backport of the kernel packages. They are stand alone > pieces of software that nothing depends upon and depend on nothing > themselves (in the packaging sense; I know the system needs a kernel to > run). You can just down load the kernel packages of your choice. True the kernel is usually rather simple to backport, although sometimes you have had to get a newer initramfs package or similar to support the new kernel, which I count as part of backporting a kernel. > I had a problem with the kernel in lenny not supporting the Nikon D40 > DSLR I've just got. Loads of stuff on the Ubuntu forums because they > shipped with a version of the kernel that was "broken". Any way I just > installed the sid kernel set and everything just worked. > > Here are the packages I got from sid: > linux-headers-2.6.23-1-amd64 2.6.23-2 > linux-headers-2.6.23-1-common 2.6.23-2 > linux-image-2.6.23-1-amd64 2.6.23-2 > linux-kbuild-2.6.23 2.6.23-1 -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intel (s775) Johannesburg DQ35JOE mATX
Len, Gudjon On Wed, 2008-01-23 at 12:37 -0500, Lennart Sorensen wrote: > On Wed, Jan 23, 2008 at 05:15:22PM +0100, Gudjon I. Gudjonsson wrote: > > > > Network card: Intel 82566DM Gigabit Adapter, integrated > > Well looking at the 2.6.18 source code from etch for the kernel I see > stuff like: > ../rr1/sandbox/linux-2.6/linux-2.6-2.6.18.dfsg.1/drivers/net/e1000/e1000_hw.c: > e1000_set_pci_ex_no_snoop(hw, PCI_EX_82566_SNOOP_ALL); > so yes I think the e1000 driver should work on that chip. > > The onboard video if you are using it, is a GMA3100 which from what I > can determine requires Xorg 1.3 or higher and 2.6.22 kernel or higher. > > So that means you have to use either Etch with a backported kernel, or > testing (or unstable) to get 2.6.22 kernel and new xorg if you want > graphics on the built in video. You don't need a backport of the kernel packages. They are stand alone pieces of software that nothing depends upon and depend on nothing themselves (in the packaging sense; I know the system needs a kernel to run). You can just down load the kernel packages of your choice. I had a problem with the kernel in lenny not supporting the Nikon D40 DSLR I've just got. Loads of stuff on the Ubuntu forums because they shipped with a version of the kernel that was "broken". Any way I just installed the sid kernel set and everything just worked. Here are the packages I got from sid: linux-headers-2.6.23-1-amd64 2.6.23-2 linux-headers-2.6.23-1-common 2.6.23-2 linux-image-2.6.23-1-amd64 2.6.23-2 linux-kbuild-2.6.23 2.6.23-1 Hope this helps Steve -- Steve Dobson If someone were to ask me for a short cut to sensuality, I would suggest he go shopping for a used 427 Shelby-Cobra. But it is only fair to warn you that of the 300 guys who switched to them in 1966, only two went back to women. -- Mort Sahl signature.asc Description: This is a digitally signed message part
Re: Intel (s775) Johannesburg DQ35JOE mATX
On Wed, Jan 23, 2008 at 05:15:22PM +0100, Gudjon I. Gudjonsson wrote: >Sorry for abusing your time but I am going to buy a computer with the > following ingredients. I am quite worried that I might have to wait for > half a year for support of some of the chips so I decided to ask first > if someone has used this (with good or bad experience): > > Motherboard: Intel (s775) Johannesburg DQ35JOE mATX I have only used a few Intel boards myself, but I wouldn't buy one. I only buy Asus boards. There has been a lot of trouble for people with more than 3GB ram and getting the MTRR cache setup right on intel boards in the last year, and it has taken a lot of pushing to even get intel to admit they screwed up their bios, while Gigabyte and Asus had a new bios within days of being notified of the mistake in intel's reference code. Not what I would consider a well supported board. Most affected users were windows 64bit users who got a very very slow system if they had more than 3GB ram installed, and linux gets the same slow performance since the top of ram is not cached and hence very slow. > Chipset: Intel Q35 Express Well intel chipsets are generally very well supported. They make good chipsets. > I am sure the following will work, I think the e1000 driver supports the > network card. > CPU: Intel Core2Quad Q6600 2,4GHz 1066/8MB s-775 No problem on the CPU. I just bought one myself I am about to play with. > Network card: Intel 82566DM Gigabit Adapter, integrated Well looking at the 2.6.18 source code from etch for the kernel I see stuff like: ../rr1/sandbox/linux-2.6/linux-2.6-2.6.18.dfsg.1/drivers/net/e1000/e1000_hw.c: e1000_set_pci_ex_no_snoop(hw, PCI_EX_82566_SNOOP_ALL); so yes I think the e1000 driver should work on that chip. The onboard video if you are using it, is a GMA3100 which from what I can determine requires Xorg 1.3 or higher and 2.6.22 kernel or higher. So that means you have to use either Etch with a backported kernel, or testing (or unstable) to get 2.6.22 kernel and new xorg if you want graphics on the built in video. I just got this combination, which should work as far as I can tell. I will find out soon: Q6600 Asus P5K 2GB PC6400 ram (2 x 1GB) Nvidia 8600GT video card The P5K uses an atl1 network chip, which certainly is supported in 2.6.22 (no idea about 2.6.18 in Etch but that's OK since the machine will be running unstable anyhow). Also has a jmicron PATA/SATA controller which I think should work with my PX760 DVD drive. I sure hope so, otherwise I will get a PATA to SATA adapter and use it that way. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Intel (s775) Johannesburg DQ35JOE mATX
Hi Sorry for abusing your time but I am going to buy a computer with the following ingredients. I am quite worried that I might have to wait for half a year for support of some of the chips so I decided to ask first if someone has used this (with good or bad experience): Motherboard: Intel (s775) Johannesburg DQ35JOE mATX Chipset: Intel Q35 Express I am sure the following will work, I think the e1000 driver supports the network card. CPU: Intel Core2Quad Q6600 2,4GHz 1066/8MB s-775 Network card: Intel 82566DM Gigabit Adapter, integrated Thanks Gudjon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
