>> How can I tell where scsi_free() comes from? I'm guessing that it's from >> the aic7xxx driver but how can I tell? > When you find a suspect routine, grep the kernel sources for it. Duhhh... sorry, forgot to engage brain.
>> > The last time I used this technique, BTW, I identified some buggy SCSI >> > module code. >> Hummmmm.... sounds familiar.... > I don't remember if I bombed in scsi_free() - the bug I found was > elsewhere, but the actual meltdown might have happened in a call to > scsi_free(). Bombing in memory allocation code reflects mistakes made > elsewhere - which is why it's often useful to build several layers > of traceback. As a workaround I noticed that there is an old aic7xxx driver. I started using that rather than the new one and everything was peachy. >> > After some grueling detective work, I found a message >> > somewhere that said, "oops, I forgot to propagate my Adaptec fix from >> > this aic79xx module to this aic7xxx module"... found the patch, >> applied >> > it to my Gentoo sources, and was back in business. >> I don't suppose that patch is still missing from the gentoo sources is >> it? >> I'm gussing not.... that would be *to* easy. >> Without getting you to do my work for me, where should I go looking for >> things relating to this? What should I look for? > > Nope - gentoo-sources is still at the release that I patched. I thought > Gentoo would rather track patches released from kernel.org rather than > get them ad hoc from users, but maybe I was just being lazy. After reading this I tryed to comprehend kernel patch management and failed :( It's a complicated world and I have no guide. There is little explanation of the orginisation of it all. However I did run across the gs-sources ebuild in my readings. It's closer to what I need (headless server), it's keept upto date (2.4.22 over gentoo-sources 2.4.20) and best of all it works! I would have liked to understand all the patch stuff but for now I'm all set ;) Nick -- [EMAIL PROTECTED] mailing list
