[gentoo-amd64] Re: mtrr: base is not aligned
Mark Knecht posted [EMAIL PROTECTED], excerpted below, on Sat, 15 Oct 2005 11:18:12 -0700: Is anyone else seeign these troubling messages from tie to time? mtrr: base(0xe802) is not aligned on a size(0x40) boundary mtrr: type mismatch for e800,800 old: write-back new: write-combining mtrr: type mismatch for e800,800 old: write-back new: write-combining mtrr: type mismatch for e800,800 old: write-back new: write-combining mtrr: base(0xe802) is not aligned on a size(0x40) boundary mtrr: type mismatch for e800,800 old: write-back new: write-combining mtrr: base(0xe802) is not aligned on a size(0x40) boundary mtrr: type mismatch for e800,800 old: write-back new: write-combining mtrr: base(0xe802) is not aligned on a size(0x40) boundary mtrr: type mismatch for e800,800 old: write-back new: write-combining Is there somethign I should be doing to fix this? You may well know more about this than I do, but on the off chance this may be new to you and for others... (and because I'm googling and learning a bit in the process myself... =8^) mtrr=memory type range (or region) register. This is definitely kernel domain we are talking about here, often video drivers (so xorg related as well). Here's a link to an old but decently Engish explanation of what MTRRs are that doesn't get too technical, but gives you some idea of not only what the theory does, but the effects on real-world performance. (It's talking PentiumPro/PII CPUs and kernel 2.2.0 or later... I /said/ it was old! =8^) http://www.meduna.org/txt_mtrr_en.html Paraphrasing from the above link... Basically, the MTRRs determine the behavior of cache vs regular memory on memory-write, for various memory regions/ranges. * Write-thru means the write is to cache and main memory together, slower than Write-back or Write-combining below but most reliable as any DMAs from main memory are guaranteed to be up-to-date. * Write-back is far faster, allowing the CPU to write to cache only then go about its business, with the update to main memory happening as memory bandwidth permits. The catch is that cache (play on words there! g) and main memory can be out of sync momentarily, which could mean either longer waits for the update to happen when it /has/ to happen (if everything is working right and the out-of-date-data is caught and a wait forced until it's updated to valid data when needed), or in the worst-case scenario, if something's not quite working right, glitches, instability and crashes because old and invalid data was used where updated data was expected. * Write-combining is sort of in-between the two above choices. The data is allowed to sit in cache without updating main memory only a comparatively short period, in ordered to allow the possibility of combining several smaller writes into a larger, single, more efficient write. (More efficient because each write has a set amount of overhead in setup and take-down time and data. Thus, combining 8 128-byte transactions into a single 1KB transaction means 1/8 the overhead, thus more effective payload bandwidth, at a cost of more latency, due to waiting for several transactions to accumulate, provided of course they come in before the expiry time forces what's there to be written even if it's not yet a full size transfer.) * There's also uncachable, which turns off caching for reads as well as writes. This will be /very/ slow. Where graphics gets involved is that these MTRRs are often used to program access to video memory over the AGP or whatever bus. The link above lists some of the (then) xfree86 operations that MTRR settings affect and by how much. Another link with some interesting info on the kernel config option (CONFIG_MTRR) and the userland interface to MTRRs (/proc/mtrr) once enabled. The two paragraphs below are excerpted: http://developer.osdl.org/dev/robustmutexes/src/fusyn.hg/Documentation/mtrr.txt The CONFIG_MTRR option creates a /proc/mtrr file which may be used to manipulate your MTRRs. Typically the X server should use this. This should have a reasonably generic interface so that similar control registers on other processors can be easily supported. There are two interfaces to /proc/mtrr: one is an ASCII interface which allows you to read and write. The other is an ioctl() interface. The ASCII interface is meant for administration. The ioctl() interface is meant for C programs (i.e. the X server). The interfaces are described below, with sample commands and C code. /quote Finally, this, on the mtrr_add command from kernelnewbies: http://kernelnewbies.org/documents/kdoc/kernel-api/r7666.html Memory type region registers control the caching on newer Intel and non Intel processors. This function allows drivers to request an MTRR is added. The details and hardware specifics of each processor's implementation are hidden from the caller, but nevertheless the caller should
Re: [gentoo-amd64] OT: CPU Temperature
On 10/16/05, Hemmann, Volker Armin [EMAIL PROTECTED] wrote: the onboard sensors are crap. You can take a look at bios cpu monitoring suite. On ASUS mobo it shows also cpu core temperature, so you can adjust lm_sensors ranges and multipliers. -- Paolo Ripamonti e-mail [EMAIL PROTECTED] web-site http://paoloripamonti.too.it Tel: (+39) 02.30.31.29.970 --- I murmured a vow of silence and now I don't even hear when I think aloud -- Pink Floyd -- -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: mtrr: base is not aligned
On 10/16/05, Duncan [EMAIL PROTECTED] wrote: Mark Knecht posted [EMAIL PROTECTED], excerpted below, on Sat, 15 Oct 2005 11:18:12 -0700: Is anyone else seeign these troubling messages from tie to time? mtrr: base(0xe802) is not aligned on a size(0x40) boundary mtrr: type mismatch for e800,800 old: write-back new: write-combining mtrr: type mismatch for e800,800 old: write-back new: write-combining mtrr: type mismatch for e800,800 old: write-back new: write-combining mtrr: base(0xe802) is not aligned on a size(0x40) boundary mtrr: type mismatch for e800,800 old: write-back new: write-combining mtrr: base(0xe802) is not aligned on a size(0x40) boundary mtrr: type mismatch for e800,800 old: write-back new: write-combining mtrr: base(0xe802) is not aligned on a size(0x40) boundary mtrr: type mismatch for e800,800 old: write-back new: write-combining Is there somethign I should be doing to fix this? You may well know more about this than I do, but on the off chance this may be new to you and for others... (and because I'm googling and learning a bit in the process myself... =8^) Duncan, Great post. I'm getting some really good stuff out of it. Time to fess up. Based on reading this and looking again this morning I'm embarrassed to say that the machine that is failing is actually an Intel P4HT machine, not an AMD64 machine. I do have an AMD64 machine and I guess I blanked out at the moment I sent the email. None the less I think the topic is valuable on either list and I cannot imagine getting a more detailed and comprehensive response from anyone. Thanks! mtrr=memory type range (or region) register. This is definitely kernel domain we are talking about here, often video drivers (so xorg related as well). Yes, this I knew. Until reading you post I thought it was only used for video memory, and from my hardware background (PC chipset/AGP stuff some years ago) specifically with write-combining. I see that it really can have more wide ranging uses. SNIP http://www.meduna.org/txt_mtrr_en.html Paraphrasing from the above link... Basically, the MTRRs determine the behavior of cache vs regular memory on memory-write, for various memory regions/ranges. SNIP * Write-combining is sort of in-between the two above choices. The data is allowed to sit in cache without updating main memory only a comparatively short period, in ordered to allow the possibility of combining several smaller writes into a larger, single, more efficient write. (More efficient because each write has a set amount of overhead in setup and take-down time and data. Thus, combining 8 128-byte transactions into a single 1KB transaction means 1/8 the overhead, thus more effective payload bandwidth, at a cost of more latency, due to waiting for several transactions to accumulate, provided of course they come in before the expiry time forces what's there to be written even if it's not yet a full size transfer.) There was a totally related, but slightly additional use for write combining at the hardware level. It was introduced by Intel when they first wrote the AGP 1.0 spec. The idea at the time was that game software doing 3D work does not naturally output memory chunks that are the same width as the AGP bus. Typically they are smaller blocks, like 2 bytes, 4 bytes, etc. For this reason, to keep transfers on the AGP bus more efficient, write combining could be set up so that the processor would hold a number of small writes in a single cache line and only flush this cache line over the AGP bus to the video display when the software moved off the cache line or over-wrote some dirty part of the cache line. The idea was that there was no reason to send a bunch of bytes in separate writes, using more AGP bus bandwidth, when these writes could be sent as a group using less bandwidth. The description above supports this but it's not specifically graphics oriented. * There's also uncachable, which turns off caching for reads as well as writes. This will be /very/ slow. Where graphics gets involved is that these MTRRs are often used to program access to video memory over the AGP or whatever bus. The link above lists some of the (then) xfree86 operations that MTRR settings affect and by how much. Yep. Another link with some interesting info on the kernel config option (CONFIG_MTRR) and the userland interface to MTRRs (/proc/mtrr) once enabled. The two paragraphs below are excerpted: http://developer.osdl.org/dev/robustmutexes/src/fusyn.hg/Documentation/mtrr.txt This one is interesting in that it opens my eyes to the possibility of defining more MTRRs, a concept that I hadn't considered before. SNIP Memory type region registers control the caching on newer Intel and non Intel processors. This function allows drivers to request an MTRR is added. The details and
[gentoo-amd64] [OT] test, please ignore.
Now there you go. FFI. Failure to Follow Instructions. :) Looking at buying a new MB and processor so thought I'd listen in on amd64 and (possibly) dual-core issues under gentoo. Yes, am reading the docs also. :) jason. -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] OT: CPU Temperature
On Mon, 2005-10-17 at 10:58 +1300, Joel Wiramu Pauling wrote: For amd64 chips you should be using conservative governor... not ondemand. There are issues with the way the amd64 powernow steping works, which the conservative governor does a better job of handling. What are those issues? I've never had any trouble with ondemand, and the only thing I can find is something about latency issues on frequency switches, which I haven't ever noticed...is it just better to use conservative, or will ondemand break hardware stuff? Kyle Liddell -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Errors when doing an emerge -uD world
I get an error like this: Unpacking source... Unpacking jdepend-2.8.1.zip to /var/tmp/portage/jdepend-2.8.1/work Source unpacked. Traceback (most recent call last): File /usr/bin/java-config, line 14, in ? from java_config import jc_options ImportError: No module named java_config Error: JAVA_HOME is not defined correctly. We cannot execute !!! ERROR: dev-java/jdepend-2.8.1 failed. !!! Function src_compile, Line 30, Exitcode 1 !!! Failed Compiling !!! If you need support, post the topmost build error, NOT this status message. Relevant environment variables are: JAVAC=/opt/blackdown-jdk-1.4.2.02/bin/javac JAVA_HOME=/opt/blackdown-jdk-1.4.2.02 JDK_HOME=/opt/blackdown-jdk-1.4.2.02 I have search on bugs.gentoo.org but can't find anything to help me. Can anyone offer me any assistance? -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Errors when doing an emerge -uD world
You're missing a package (for some unknown reason) Try this: emerge dev-java/java-config On Monday 17 October 2005 03:14, Jamie Dobbs wrote: I get an error like this: Unpacking source... Unpacking jdepend-2.8.1.zip to /var/tmp/portage/jdepend-2.8.1/work Source unpacked. Traceback (most recent call last): File /usr/bin/java-config, line 14, in ? from java_config import jc_options ImportError: No module named java_config Error: JAVA_HOME is not defined correctly. We cannot execute !!! ERROR: dev-java/jdepend-2.8.1 failed. !!! Function src_compile, Line 30, Exitcode 1 !!! Failed Compiling !!! If you need support, post the topmost build error, NOT this status message. Relevant environment variables are: JAVAC=/opt/blackdown-jdk-1.4.2.02/bin/javac JAVA_HOME=/opt/blackdown-jdk-1.4.2.02 JDK_HOME=/opt/blackdown-jdk-1.4.2.02 I have search on bugs.gentoo.org but can't find anything to help me. Can anyone offer me any assistance? -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Errors when doing an emerge -uD world
On Monday 17 October 2005 03:14, Jamie Dobbs wrote: I get an error like this: Unpacking source... Unpacking jdepend-2.8.1.zip to /var/tmp/portage/jdepend-2.8.1/work Source unpacked. Traceback (most recent call last): File /usr/bin/java-config, line 14, in ? from java_config import jc_options ImportError: No module named java_config Error: JAVA_HOME is not defined correctly. We cannot execute !!! ERROR: dev-java/jdepend-2.8.1 failed. !!! Function src_compile, Line 30, Exitcode 1 !!! Failed Compiling !!! If you need support, post the topmost build error, NOT this status message. emm, is not -uD something almost everybody does, but nobody should do? I had the same error - AFAIR reemerging java-config solved it. -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] OT: CPU Temperature
Kyle Liddell [EMAIL PROTECTED] wrote: is it just better to use conservative, or will ondemand break hardware stuff? I think I've been using ondemand, and I haven't yet seen icicles forming or anything like that due to insufficient power dissipation. :) -- [EMAIL PROTECTED] http://www.chemoelectric.org Esperantistoj rajtas skribi al [EMAIL PROTECTED] 'And now we're going to go try to comfort people in that part of the world.' -- Bush, referring to the southeastern U.S. pgp91dJUzJeme.pgp Description: PGP signature
Re: [gentoo-amd64] Errors when doing an emerge -uD world
You're missing a package (for some unknown reason) Try this: emerge dev-java/java-config Thank-you! That worked perfectly. That's what I love about Gentoo, the support within the community is second to none! -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Courier won't start... And Courier tls doesn't work
On Thursday 13 October 2005 21:29, Hamish Marson wrote: Then I updated to 2005.0 because syncing portage (emerge --sync) told me I was deprecated, and needed to update to the latest greatest. FWIW, I am simply refusing to change profiles. If they delete it, I'll probably just move the old one to /usr/local/portage... -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Errors when doing an emerge -uD world
emm, is not -uD something almost everybody does, but nobody should do? I had the same error - AFAIR reemerging java-config solved it. No, -uD is update deep, -UD is what you should NOT be doing. the U means update only. The difference is if say package-1.45 was marked stable and then found to be buggy, it gets masked in some way. Then package-1.44 would be the most current stable package. The U flag says not to go back to the 1.44 package. On the other hand, the -u flag will upgrade to an older package if it is currently the newest unmasked or stable package. I think the biggest problem, I could be wrong thoug, is that usually when packages get remasked like that and upgrades go backwards, it is a security problem. And even that seems to be uncommon. I have not ever seen one of my packages go backwards but I could have missed one or two. -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Problem when mounting usb-drive
I got a problem with my thumb-drive. Most thumbdrive do not work with my PC. The error from dmesg is as below. I am suspecting some driver error. Does 64-bit driver won't compiled smoothly for the device? Currently, i am using 2.6.9 kernel. Also no luck when upgrading the kernel to 2.6.12 and 2.6.13. Error from dmesg:- $ dmesg ... usb 1-6: new high speed USB device using address 16 usb 1-6: control timeout on ep0out usb 1-6: control timeout on ep0out usb 1-6: device not accepting address 16, error -110 usb 1-6: new high speed USB device using address 17 ... The funny thing is, I got no problem when using 32-bit Knoppix on my PC. All thumbdrive can be mount perfectly. (How does it feel when you need to reboot pc just to copy files to thumdrive?) Dmesg output from Knoppix $ dmesg .. ohci_hcd :00:02.1: wakeup usb 3-3: new full speed USB device using address 4 scsi5 : SCSI emulation for USB Mass Storage devices Vendor: KINGSTON Model: USB DRIVE Rev: 1.12 Type: Direct-Access ANSI SCSI revision: 02 SCSI device sdb: 251904 512-byte hdwr sectors (129 MB) sdb: assuming Write Enabled sdb: assuming drive cache: write through sdb: sdb1 Attached scsi removable disk sdb at scsi5, channel 0, id 0, lun 0 Attached scsi generic sg2 at scsi5, channel 0, id 0, lun 0, type 0 USB Mass Storage device found at 4 -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] OT: CPU Temperature
On Sat, October 15, 2005 2:27 pm, Jamie Dobbs wrote: Motherboard sensors indicate that the CPU core is running at a constant 65 degrees Celcius and this figure does not change more than a degree Should I be worried about these figures? The heatsink feels only slightly warm to the touch and I am sure it is seated correctly so I wonder if the BIOS is reporting the right temperatures. Does anyone have the same board that can help me out here? Well, either it isn't seated correctly or doesn't have thermal compound and so the heatsink isn't at the same temperature as the CPU, or the sensor is worthless. My money is on the latter if you're sure you know what you're doing. If you touch something at 65C you're going to notice it FAST - set your kitchen oven to a low setting and try touching the rack (then again, don't - I don't need a lawsuit). If your BIOS can display CPU temp, try looking at it right after a cold start. I would think that shouldn't be that hot until at least a minute or two of real work is done. A few months ago I was having heat issues when I'd make the box work real hard. It would hit about 60C and sometime later it would get flaky. Since then I've tried to avoid over-multitasking. My guess is that a new RAM module I installed is responsible... -- gentoo-amd64@gentoo.org mailing list
