[LUNI] Prolink DC-305 support in Linux
eugene.teo at eugeneteo.net
Fri Dec 14 19:56:03 CST 2001
On Fri, Dec 14, 2001 at 04:52:32PM -0600, Martin Maney wrote:
> On Sat, Dec 15, 2001 at 01:30:35AM +0800, Eugene Teo wrote:
> > Where can I get to see the code you wrote for ECC module? Just being
> > curious and excited to see more new stuffs!
> The project's home page is at http://www.anime.net/~goemon/linux-ecc/
> The code I wrote (and I don't recall if I gave Dan entirely working code or
> is there were a few spots of pseudo-code in it at the time) is the
> generic_check routine, which added a bunch of parameters stored in the
> ChipsetInfo structure. I'm still using a significantly modified version of
> what was released as version 0.11; from a fairly brief look at the latest
> release, it seems that quite a few new chipsets have been added using the
> old CHIPSET_NAME_check() approach. I haven't had the time to see if that's
> because the newer chipsets have requirements not supported by my original
> synthesis or if they were just hacked in that way and haven't been
> integrated. Or perhaps some of both...
It happens I suppose. Unless you keep track of the hack/patch in every
versions, you probably won't know what happened to it. Just like my
contributions to QmailAdmin. Now I have to spend some time working on it
just to port one of my patch to a new version due to popular demand.
> > Panic'ng the box isn't fun at all. Probably run VMWARE for it maybe?
> VMWARE might be usable as long as you're dealing with abstractions above the
> level of its virtualization. The ECC code needs to poke at the hardware
> itself, so that probably wouldn't have worked for that.
> > > memo: never run untested kernel code, no matter how trivial, on a machine
> > > that's in X. You won't see the panic report that way.
> > Nods, took note of this important advice.
> Good thing to learn from someone else's mistake. Of course, sometimes it's
> hard to be sure that you really have tested every code path, especially when
> some of them only get followed under rare conditions.
I take people's advice and tips seriously, and always learn as I go :)
But when I do not have access to these, I just go back to trial and
error and pray things don't go wrong (that already happened on others :)
> Oh well, if you haven't got the panic details you'll just have to meditate
> on the code until enlightenment arrives. Worked for me! :-)
Hahaha... nice tip ;P
> > Materials online? The only one I came across is a document on a 2.1.x or
> > 2.2.x kernel at linuxdocs.org. Is that the document you are referring?
> That would be one of them. Sifting through the bookmarks...
> http://linux-mm.org/ memory management, the dark art of
> (and poke around kernelnewbies in general: it's made for us
> non-hard-core kernel dilletantes)
> an amazing thing. see the "online book" link? :-)
> I thought I had a couple of others that should have been in that list.
> Maybe they're on the bookmark list on the machine in the lab. I try to
> merge the good stuff, but stuff happens.
Wow. That is a lot of urls. I really appreciate that you shared your
bookmarks with me, otherwise I wouldn't have known these urls already.
Thanks a lot.
> Oh, and the Kernel Mailing List can be a source of much enlightenment. It's
> too big for most mortals, but there's quite a nice summary of the highlights
> (and sometimes lowlights) at http://kt.zork.net/kernel-traffic/
> I didn't write a whole, free operating system, either. I wrote some pieces
> and invited other people to join me by writing other pieces. So I set an
> example. I said, "I'm going in this direction. Join me and we'll get
> there." And enough people joined in that we got there. -- R M Stallman
> Linux Users Of Northern Illinois - Technical Discussion
> luni at luni.org
eMail: eugene.teo at eugeneteo.net, admin at spug.org
www: http://www.eugeneteo.net/, http://www.spug.org/
More information about the luni