looking for a linux expert to write a Linux boot loader for memory testing
joe...@gmail.com
free-lancers or any software programmers who are skilled with Linux OS.
I need someone who can code programs using Linux.
This project is fairly simple , we need someone to custom a Linux
Bootloader which will reside in USB flash memory stick, when this USB
stick is connected to the USB port of any Desktop system - , the system
will boot from this USB stick, and test the memory for defect.We have
already designed the hardware but need a skilled Linux programmer to
get the Linux Bootloader develop for this application.
Currently - we are using a DOS base boot loader and the limitation of
DOS is it can only support up to 4GB main memory.
We will pay an hourly rate and a non-compete agreement is neccessary
for more detail release
can u reply to joe...@gmail.com
Wolfgang Draxinger
> This project is fairly simple , we need someone to custom a
> Linux Bootloader which will reside in USB flash memory stick,
> when this USB stick is connected to the USB port of any Desktop
> system - , the system will boot from this USB stick, and test
> the memory for defect.
Sounds like memtest86 <http://www.memtest86.com/>
Wolfgang Draxinger
--
![Basile Starynkevitch [news]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Basile Starynkevitch [news]
> My company have a small software projects and we are looking to find
> free-lancers or any software programmers who are skilled with Linux OS.
> I need someone who can code programs using Linux.
>
> This project is fairly simple , we need someone to custom a Linux
> Bootloader which will reside in USB flash memory stick, when this USB
> stick is connected to the USB port of any Desktop system - , the system
> will boot from this USB stick, and test the memory for defect.We have
> already designed the hardware but need a skilled Linux programmer to
> get the Linux Bootloader develop for this application.
Did you consider using memtest86 for this purpose?
See http://www.memtest86.com/
> Currently - we are using a DOS base boot loader and the limitation of
> DOS is it can only support up to 4GB main memory.
>
> We will pay an hourly rate and a non-compete agreement is neccessary
> for more detail release
I am not candidate, but I think you probably misunderstood or forget
what is GPL-ed software. Your programmer would probably start from
some GPL-ed program and and adapt it. Hence, hsi resulting program is
also under GPL license. So wehn you'll distribute it, you'll have to
give the sources under GPL license also. See
http://www.gnu.org/licenses/ for more
You'll better reformulate your quest, like: we are seeking for a
competent opensource programmer to develop or adapt an open-source
GPL-ed program to test some memory. This may mean adapting memtest86
to your needs, and this requires a GPL license (on the modified
software)!
And be sure that no competent programmer would accept to violate the
GPL license (because that would ruin his reputation)...
It could be the case that not a single line of Linux code is required,
but that it is needed to merge & adapt several GPL-ed free software
(making another GPL-ed free software)
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net
aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net
8, rue de la Faïencerie, 92340 Bourg La Reine, France
zentara
This has already been done. Check out
http://damnsmalllinux.org/usb.html
or
http://featherlinux.berlios.de/
If I were you, I would contact the authors of those projects,
and ask them how much they would charge to customize
them for you, to include and run memtest86.
--
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html
Randy Howard
zen...@highstream.net says...
>
> If I were you, I would contact the authors of those projects,
> and ask them how much they would charge to customize
> them for you, to include and run memtest86.
The mistake is in believing that memtest86 is rigorous.
Especially on SMP or dual-core hardware. If he *really*
wants to test memory or platform signal integrity on
serious hardware, he needs a lot more than what it
provides.
--
Randy Howard (2reply remove FOOBAR)
"Making it hard to do stupid things often makes it hard
to do smart ones too." -- Andrew Koenig
Kasper Dupont
>
> The mistake is in believing that memtest86 is rigorous.
> Especially on SMP or dual-core hardware. If he *really*
> wants to test memory or platform signal integrity on
> serious hardware, he needs a lot more than what it
> provides.
Why do you think SMP makes any difference to memtest86?
It is after all not testing the CPU, but the memory. Of
course with a faulty CPU memtest86 might report errors
even if there is nothing wrong with the memory. But that
is not much of a problem.
--
Kasper Dupont
Randy Howard
says...
> Randy Howard wrote:
> >
> > The mistake is in believing that memtest86 is rigorous.
> > Especially on SMP or dual-core hardware. If he *really*
> > wants to test memory or platform signal integrity on
> > serious hardware, he needs a lot more than what it
> > provides.
>
> Why do you think SMP makes any difference to memtest86?
It doesn't. That's the whole point. However, testing
memory on SMP systems from a single thread is not
exhaustive. This is especially true on NUMA systems like
Opteron. If you think you're hitting a 4-way Xeon
server's memory subsystem as hard with a single instance
of memtest86 versus 4 hot threads, one on each CPU, you're
just mistaken.
It will miss a lot of memory and underlying signal integrity
issues. Not to mention the incredibly weak complement of
data patterns used by memtest86. Last I looked, it completely
ignored simultaneous switching output noise stress, although
it would be nice to hear that's been improved.
The serious PC hardware vendors don't use it for bringup and
module qual testing because it doesn't find enough faults.
They're perfectly happy that customers use it though, since they
are less likely to call in for support afterward.
I've written memory test software for IA32, IA64 and x86-64 and
PowerPC platforms that has been used for testing memory on the
bulk of the big name vendors in the industry. It will find
issues in some cases in < 10 minutes on hardware that memtest86
will run a week on without finding any fault at all.
memtest86 is fine for sniffing out very obvious memory problems
for the typical consumer that just ordered a memory upgrade.
It's of very little value going after the more subtle issues
that pop up during the design phase of a new platform or
qualifying memory vendors, especially for server and workstation
platforms.
Kasper Dupont
>
> I've written memory test software for IA32, IA64 and x86-64 and
> PowerPC platforms that has been used for testing memory on the
> bulk of the big name vendors in the industry. It will find
> issues in some cases in < 10 minutes on hardware that memtest86
> will run a week on without finding any fault at all.
Then please tell me how it should be done. I'm currently
considering writing my own memory testing software, and if it
can be done faster and more reliable than memtest86 I'd
definitely want to know how I should do it.
--
Kasper Dupont
Randy Howard
says...
I was paid to do it, and it wasn't open source, so I can't
describe the specifics or give out code.
I have considered writing it again from scratch and making
it open source, but I'm not 100% sure on what I can and
can't do or say there, not being a lawyer or having a
corporate legal department to hide behind for it.
I think it would make life much harder on hardware
vendors if this software was available in the wild
instead of just in hardware test labs so customers
could make them feel the pain of shipping with
known issues they hope you won't find. :-)
In general, here are some things to consider though...
First off, the most important thing is having the correct
data patterns. Note the plural. You can not predict
ahead of time which will find a fault on a given platform,
it will often vary wildly, although there are a few that
are really good and have high hit rates.
Surprisingly, the ones used by memory module vendors in
isolation to look for address and data line faults and such
in automated chip testers are NOT typically very useful in
integrated system testing of memory subsystems.
Knowing which data patterns to use is the "art" part of it,
although if you have the time, brute force through them
all will work.
I won't enumerate them all here, but if you have less than
70 unique patterns in your playbook, you aren't going to
be very exhaustive. Many of those are subtle variations or
bit-shifts of others though, so it isn't as bad as that
sounds. If you really cover all your bases, there will
be a lot more. People that do this for money know what most
of them are, but seem to think the knowledge is valuable, it
is very difficult to find it written down anywhere, they seem
to try and keep it a secret, one of the reasons I would like
to put an open source package together. 99% of the important
stuff is in this paragraph, but 99% of the details are missing
for now. Sorry.
You want to pin down as much memory as possible per thread
(or process), one per CPU (without paging obviously). Having
lots of threads with smaller memory pinned down in each
just bottlenecks the CPU. If you have more than 4GB of RAM
on a 32-bit system (PAE), you'll have to be creative about
how to test it all at once without making things slow down
too much. Nuff said.
Hyperthreading sucks, and will actually slow you down for
this, so turn it off, or figure out how to guarantee you
have half as many threads running, and they are on the
"real" cpus, not the virtual ones if you have more than
one physical CPU. Dual core is a different story.
memcpy() and memcmp() may or may not be fast enough
depending on your implementation, and inline assembly
may be required.
Play around with the transfer sizes, depending upon the CPU and
its ability to do bulk moves, bigger is generally better. Malloc
N, and ping pong N/2 sized blocks back and forth may work well
quite often, but when you have massive RAM on 64-bit hardware,
you'll probably want a different approach, or timing statistics
may be tricky. :-)
How you malloc memory on NUMA hardware can have massive performance
implications. Enjoy.
If you are running on a modern, fast system, with say DDR 2700
memory, then you should be able to pull about 2700MB/s through the
test tool. (Intel designs). Opteron/Hypertransport systems with
multiple CPUs should be much higher (think almost linear scaling of
memory throughput). Use a single CPU on Opteron to baseline
relative to the expected speed from the memory rating.
On Xeon SMP, you won't go faster, you'll just be able to pin down
more memory. Memory thoughput doesn't scale at all (outside of
cache) on Intel.
This will vary depending upon whether you are doing all reads (after
filling with a pattern) and comparing, read/write ping-pongs, etc.
They're all important, but the performance will vary depending upon
the way the vendor has programmed the chipset and possibly microcode
in the processor itself. It's just a rule of thumb to let you know
if you are in the right ballpark or not.
This is true under Windows or Linux actually, done right, you won't
see any measurable difference between them for memory throughput.
Running different data patterns in each thread, instead of the same
pattern in each is a good idea, but not always, so make it optional.
It *IS* possible to see memory corruption without system lockups,
even with ECC systems doing this testing, because sometimes the fault
is in the OS itself, or an interaction with drivers, and the memory
hardware doesn't see the fault. This is especially true with bounce
buffers, >4GB of RAM, DMA options, etc. Both Windows and Linux
(and driver writers) have had problems in this area in the past, most
of them are probably aware of how to avoid it by now. Anyway, don't
decide you don't need to be able to dump expected/actual data on
miscompares. If it's truly a hardware memory error, you'll NMI, but
that's not always the way it fails.
If it's not already obvious, if you're not getting memory reads and
writes as fast as possible, your not trying hard enough and the
results will suffer.
That's probably more than enough for you to chew on for now, but
there are a lot more issues involved, they're just difficult to
desribe this way.
Paul Pluzhnikov
> People that do this for money know what most
> of them are, but seem to think the knowledge is valuable, it
> is very difficult to find it written down anywhere,
Some of the patterns are described in "Programming Embedded Systems
in C and C++" by Michael Barr.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
Randy Howard
n...@charter.net says...
> Randy Howard <randy...@FOOverizonBAR.net> writes:
>
> > People that do this for money know what most
> > of them are, but seem to think the knowledge is valuable, it
> > is very difficult to find it written down anywhere,
>
> Some of the patterns are described in "Programming Embedded Systems
> in C and C++" by Michael Barr.
Is that the one for the 80186? If so, I never picked it up.
Paul Pluzhnikov
>> "Programming Embedded Systems in C and C++" by Michael Barr.
>
> Is that the one for the 80186? If so, I never picked it up.
From the Appendix:
"All of the examples in this book have been written for and tested
on ... Arcom's Target1188EB. ... Processor: Intel 80188EB"
The book itself is very generic and (IMHO) quite good introduction
to programming embedded systems [but, having done none of it at all,
my opinion should count for very little :]
William Park
> On 22 Apr 2005 08:21:52 -0700, joe...@gmail.com wrote:
>
> >My company have a small software projects and we are looking to find
> >free-lancers or any software programmers who are skilled with Linux OS.
> >I need someone who can code programs using Linux.
> >
> >This project is fairly simple , we need someone to custom a Linux
> >Bootloader which will reside in USB flash memory stick, when this USB
> >stick is connected to the USB port of any Desktop system - , the system
> >will boot from this USB stick, and test the memory for defect.We have
> >already designed the hardware but need a skilled Linux programmer to
> >get the Linux Bootloader develop for this application.
> >
> >Currently - we are using a DOS base boot loader and the limitation of
> >DOS is it can only support up to 4GB main memory.
> >
> >We will pay an hourly rate and a non-compete agreement is neccessary
> >for more detail release
> >
> >can u reply to joe...@gmail.com
>
> This has already been done. Check out
> http://damnsmalllinux.org/usb.html
> or
> http://featherlinux.berlios.de/
And, also
http://home.eol.ca/~parkw/thinflash.html
which is designed for Linux thin-client.
However, I think, OP is looking for assembly writer to do the memory
test before Linux kernel loads.
>
> If I were you, I would contact the authors of those projects,
> and ask them how much they would charge to customize
> them for you, to include and run memtest86.
--
William Park <openge...@yahoo.ca>, Toronto, Canada
Slackware Linux -- because it works.
Kasper Dupont
>
> I'm currently
> considering writing my own memory testing software,
http://www.daimi.au.dk/~kasperd/linux_kernel/memtest.c
Here is my first version. Testing 1000MB and able to
make 1000 passes per hour on my system. Nine hours
later it had detected two errors.
At least now I have some fundamental code which runs
and is actually able to detect some errors. I'd like
to put this into a kernel module, so I can actually
figure out what part of the memory failed and stop
using it. But first I'll want to do some more testing.
Any comments on the code?
--
Kasper Dupont
Kasper Dupont
https://www.daimi.au.dk/~kasperd/linux_kernel/kmemtest.c
It was first written for 2.6 but I commented out a few pieces
of the code to make it work in 2.4.
The background for this is, that I'd like to be able to test
memory on a running system and not having to take the system
offline for hours or even days running memtest86.
Looks like it does in fact work. In case an error is detected
I currently just execute this piece of code:
printk(KERN_CRIT "error on page %d (%d) - %d errors \n",
p[i]-mem_map,i,++errors);
Where p is an array with pointers to pages allocated with
alloc_page(). Now it would be a trivial matter to just leak
the page, but probably that is not enough to achieve a stable
system, and for the most reliable test results I should
probably keep testing the bad pages again and again.
But now I'd like to print some more useful information about
the page. What relevant information could I get from a pointer
to a struct page?
And assuming I want to test as much of the memory as possible,
are there any ways I could be more specific about which parts
of memory I want to allocate from rather than just using
alloc_page to allocate from a specific zone? If I free some
memory and try to allocate some new memory afterwards, I'd
probably just get the same.
--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.