badmem-developer Mailing List for BadMEM patches/utils for Linux Kernel
Status: Beta
Brought to you by:
eagle2
Menu
▾
▴
badmem-developer — Developing issues of the badmem system
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(5) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: Sourceforge U. <sou...@ha...> - 2004-12-01 06:27:23
|
This message is intended for Boris Gjenero. Hopefully he still reads this list. I wanted to inquire about the driver you've written. Is this something you'd be willing to share? I would have sent my request to you personally but I dont know your email address. |
|
From: Nico S. <ea...@us...> - 2004-02-23 21:24:45
|
Hi Boris, > I've been using a bad SIMM with Windows XP for over a month. I'm > using the > > MmAllocateContiguousMemorySpecifyCache function to allocate the bad > RAM: > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarc > h/hh/kmarch/k106_70 oi.asp > [...] Hey, thanks for your idea! I will have a closer look on that as soon as I got time to do. This sounds very exciting... 73 Nico EMail: ni...@sc... PGP-fingerprint: 5DDB 09E4 3FF3 CD09 7559 1117 9C03 46E3 38FC 9E03 -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d- s-:-- a-- C++ UL++ P L+++ E- W++ N+ o- K- w O- M- V- PS PE Y+ PGP++ t+ 5++ X R tv- b- DI- D G e h-- r- y+ ------END GEEK CODE BLOCK------ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Please note my special spam and email virus information at http://www.schmoigl-online.de/spam/spam.html . Thank you! Bitte beachten Sie meine speziellen Informationen zu Spam und EMail-Viren auf der Seite http://www.schmoigl-online.de/spam/spam.html . Vielen Dank! -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBPwk70ZwDRuM4/J4DEQKc2gCg73ROAg86gwuECwjbOu8eRxMPRasAoI9Q IZoZSWmFmSz0Dq53f7CsReUz =1U0h -----END PGP SIGNATURE----- 73 Nico EMail: ni...@sc... PGP-fingerprint: 5DDB 09E4 3FF3 CD09 7559 1117 9C03 46E3 38FC 9E03 -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d- s-:-- a-- C++ UL++ P L+++ E- W++ N+ o- K- w O- M- V- PS PE Y+ PGP++ t+ 5++ X R tv- b- DI- D G e h-- r- y+ ------END GEEK CODE BLOCK------ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Please note my special spam and email virus information at http://www.schmoigl-online.de/spam/spam.html . Thank you! Bitte beachten Sie meine speziellen Informationen zu Spam und EMail-Viren auf der Seite http://www.schmoigl-online.de/spam/spam.html . Vielen Dank! -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBPwk70ZwDRuM4/J4DEQKc2gCg73ROAg86gwuECwjbOu8eRxMPRasAoI9Q IZoZSWmFmSz0Dq53f7CsReUz =1U0h -----END PGP SIGNATURE----- |
|
From: Boris G. <lzx...@we...> - 2004-02-23 01:47:07
|
I've been using a bad SIMM with Windows XP for over a month. I'm using the MmAllocateContiguousMemorySpecifyCache function to allocate the bad RAM: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/kmarch/k106_70 oi.asp Since I had never actually written a Windows driver before I got a sample one and figured out how to compile it with mingw. I call the function in it's initialization and allocate the bad chunks. I then added the relevant stuff to the registry so this driver is loaded at boot. The sample driver implemented a small amount of shared memory readable through a device and I use this to verify the allocations. It could easily be extended to also allow access to the bad RAM. I haven't actually made this into something easily usable for anyone. To change the areas I exclude I need to recompile the driver. Also I haven't experimented with how much RAM is left unallocated when the driver loads. All I can say is it's stable for me and I haven't had problems allocating 4 megs at 43M or a meg at 111M with 384M installed. -- Boris http://NetMails.NET - SPAM Free Email - Advanced email for advanced species |
|
From: Yann D. <yd...@fr...> - 2004-01-19 17:33:04
|
On Fri, Jan 16, 2004 at 12:01:19PM +0100, ydirson wrote: > > Do you agree to submit your work via the badmem homepage @ > > sourceforge? > > You mean through the patch-submitting system ? That makes sense, > esp. since SF has done strange things to the list archives... > > I will probably work a bit more on this and submit that next week. I just uploaded a new version (4.9yd3) to the patch tracker. Changes from 4.9yd2: - use page_alloc::pgdat_list instead of bootmem stuff - changed layout to use /proc/memmap/node%d/<zonename> - provide separate info for all zones in a node http://sourceforge.net/tracker/index.php?func=detail&aid=879978&group_id=24797&atid=382360 Basically, that means: - no more dependency on bootmem.c stuff - support for HighMem is there (although not tested - should test at home where I have a 1.5 GB box) - /proc/memmap is a dir now, where eventually all nodes of a NUMA-like system will show up as individual dirs. For now we just have /proc/memmap/node0/{DMA,Normal,HighMem} Immediate plans: - port to 2.6, because that's what memory-hotwsap patches apply to - play with memory-hotwsap patches, which turn a UMA box into a multi-node one, and implement multi-node support in memmap - switch the file contents to 1 page per char, unformatted, and write a minimal userspace program to synthesize the display - fix other known bugs -- Yann Dirson <Yan...@fr...> http://www.alcove.com/ Technical support manager Responsable de l'assistance technique Senior Free-Software Consultant Consultant senior en Logiciels Libres Debian developer (di...@de...) Développeur Debian |
|
From: Yann D. <yd...@fr...> - 2004-01-16 11:12:57
|
On Fri, Jan 16, 2004 at 11:49:10AM +0100, Nico Schmoigl wrote: > By the way, did you fall over the effect which was reported some time > ago: > > ---- CUT ---- > [ 843096 ] /proc/badmem/badmem vs. /proc/memmap No - I have seen this report, but after splitting I only worked on a memmap-only kernel. I'll try to have a look at this. > > However, it is infinitely more comfortable to be able to rmmod and > > insmod a new version back for testing purposes. I hope this will > > encourage others to hack into this. > > Could you give me some hint, why you'd like to insmod/rmmod memmap > support? Either this linux box is a testing box or not - and > therefore I do compile my kernel. Or is it just the effect, that > you'd like to "just plug it in on a box that is sick"... Mostly, it's just that since I'm constantly changing the code, it's highly impractical to reboot each time. rmmod/insmod is way more efficient. BTW, the current patch has a problem: if you resize the display too much, data gets written outside the buffer, leading to quick panic... > > Other thoughts: > > - writing to /proc/memmap is not much flexible. We could want to add > > more parameters to tune, or get other general information. Maybe a > > set of files in a /proc/memmap-params/ or so would be cleaner. > > Indeed would be better, but with only two parameters? mmhm... seems > to be a bit "overengineered" to me... don't you think so? They're not 2 anymore, they're 4 already :) > > - a single view of the memory may not be flexible enough for some > > uses. It would be useful to keep an eye on the big picture while > > looking at precise pieces of memory in a more precise manner. > > > > That could probably be handled by a central writable file, to which we > > would write things like "myregion 0 8000", resulting in > > /proc/memmap/myregion being created to look at the specified region. > > > > I thought it would be neat to be able to say just "echo 0 8000 > > > /proc/memmap/myregion" to get that new map created, and "rm > > /proc/memmap/myregion" to free the resources, but I fear procfs may > > not be flexible enough for this. > > Got want you want. But what is the main purpose: help debugging; > multi-user capabilities are no issue to me. Yes, multi-user capabilities are no issue for me as well. It's mostly to be able to look at several places at the same time. > The only thing that could > be handy would be an "over all" map with only 1 page per character > independed of the range you selected. This could make it possible to > write user space programs that are more flexible. What do you think? That would be a possibility: a full 1p/char map would allow a userspace program to synthesize any other map. I was already thinking about making the file more machine-readable to solve the problem I mentionned above, and allow to generate in _read() just the requested data. Having this would allow a userspace to just request the required piece of data and nothing else, so that should not cause too much performance hit. Note: I'm currently digging through http://www.csn.ul.ie/~mel/projects/vm/ to find ideas of improvements. Regards, -- Yann Dirson <Yan...@fr...> http://www.alcove.com/ Technical support manager Responsable de l'assistance technique Senior Free-Software Consultant Consultant senior en Logiciels Libres Debian developer (di...@de...) Développeur Debian |
|
From: Yann D. <yd...@fr...> - 2004-01-15 13:41:06
|
On Wed, Jan 14, 2004 at 09:49:45PM +0100, ydirson wrote: > I've worked a bit on memmap today, and discovered a couple of annoying > bugs, which I could fix, at the same time as I implemented a couple of > other things. Here is the changelog: Obviously, as always I forgot the attachment... -- Yann Dirson <Yan...@fr...> http://www.alcove.com/ Technical support manager Responsable de l'assistance technique Senior Free-Software Consultant Consultant senior en Logiciels Libres Debian developer (di...@de...) Développeur Debian |
|
From: Yann D. <yd...@fr...> - 2004-01-14 20:49:56
|
Hi, I've worked a bit on memmap today, and discovered a couple of annoying bugs, which I could fix, at the same time as I implemented a couple of other things. Here is the changelog: - extracted from badmem patch, and made so that both can be applied in any order - allowed to be used as a module to ease further development - fixed displayed offset for each line to be offset for this line, not next one's - fixed calculation of dotconst to include all requested pages - moved legend from /proc/memmap into Documentation/vm/memmap - added 'x' symbol to show pages below min_low_pfn - fixed error codes to be all negative, printk a message on all errors - protect write from buffer overflow - turned on auto-detection of numeration base of numbers written to procfile, instead of forcing 10 - allow changing numbers of rows and columns Note that allowing to build memmap as a module required that the (min|max)_low_pfn symbols are exported from bootmem.c, which may not be desirable. I'm not digged much into the VM yet (memmap is supposed to help me ;), but as I understand it, there should be after boottime other means to get this information, which may already be exported. However, it is infinitely more comfortable to be able to rmmod and insmod a new version back for testing purposes. I hope this will encourage others to hack into this. Other thoughts: - writing to /proc/memmap is not much flexible. We could want to add more parameters to tune, or get other general information. Maybe a set of files in a /proc/memmap-params/ or so would be cleaner. - a single view of the memory may not be flexible enough for some uses. It would be useful to keep an eye on the big picture while looking at precise pieces of memory in a more precise manner. That could probably be handled by a central writable file, to which we would write things like "myregion 0 8000", resulting in /proc/memmap/myregion being created to look at the specified region. I thought it would be neat to be able to say just "echo 0 8000 > /proc/memmap/myregion" to get that new map created, and "rm /proc/memmap/myregion" to free the resources, but I fear procfs may not be flexible enough for this. Best regards, -- Yann Dirson <Yan...@fr...> http://www.alcove.com/ Technical support manager Responsable de l'assistance technique Senior Free-Software Consultant Consultant senior en Logiciels Libres Debian developer (di...@de...) Développeur Debian |
|
From: Yann D. <yd...@fr...> - 2004-01-13 17:05:39
|
Hi, I've the feeling that the memmap feature would be useful for other things than badmem. I'm planning to dive into the various ram hotplug patches, and this looks like a useful diagnostic tool. Not counting that it would also be useful do play with the badram patch. I've currently splitted the patch, assuming badmem would be applied after memmap, so that <linux/badmem.h> can include a new <linux/memmap.h> which only exports the 2 memmap functions. But now: 1) I wonder whether those 2 funcs should be exported at all 2) memmap.c can possibly be made into a module (I'll be experimenting that and submitting patches where applicable) whereas badram does not. So I'm now considering doing things the other way round, and attempting to have the same memmap patch applicable both on a vanilla and a badmem/badram kernel. I attach the current patches. Currently my version of the badmem patch is just a diff between the memmap-only tree and the badmem one, modulo the #include tweeking described above. Regards, -- Yann Dirson <Yan...@fr...> http://www.alcove.com/ Technical support manager Responsable de l'assistance technique Senior Free-Software Consultant Consultant senior en Logiciels Libres Debian developer (di...@de...) Développeur Debian |
|
From: Nico S. <ni...@wr...> - 2002-03-02 23:11:51
|
Hi everybody outside, with the new release I ran into some trouble on generation of the badmem patterns during the testing process of memtest86 v2.8. Version 2.7 works fine, but v2.8 is broken here; the pattern are not printed at all, although the error mode is set to "BadRAM pattern". Does anyone saw a similar behaviour? 73 Nico EMail: ni...@wr... PGP-fingerprint: 5DDB 09E4 3FF3 CD09 7559 1117 9C03 46E3 38FC 9E03 -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d- s-:-- a-- C++ UL++ P L+++ E- W++ N+ o- K- w O- M- V- PS PE Y+ PGP++ t+ 5++ X R tv- b- DI- D G e h-- r- y+ ------END GEEK CODE BLOCK------ |
