were there any hints in dmesg? hitting table size limits in i2c-core can also return ENOMEM, but should also generate a message about increasing I2C_xxx_MAX. I'd say this is more likely than running your whole box out of memory. mds James Olin Oden wrote: > On Tue, 15 Feb 2005 12:06:15 +0100 (CET), Jean Delvare > <khali at linux-fr.org> wrote: > >>Hi James, >> >>I am moving this to the mailing-list since it is likely to require some >>investigation before we can find out what's going on, and our current >>ticket system is not meant for this. (Philip, Axel, where is the new >>Bugzilla system going?) >> > > Fine by me. > > >>Most things in the i2c core in linux 2.4 are static, so I doubt that >>there can be a leak in i2c-core itself. i2c-proc OTOH is likely to >>allocate memory for various things, so this is a candidate. And, as you >>suggested yourself, individual drivers are candidates as well. >> >>Please tell us: >> >>* Which i2c drivers you are using. >> > > Here is the list in the order they are loaded: > > i2c-core i2c-dev i2c-proc i2c-i801 lm87b lm93 eeprom pcf8574 > > When I found the appearant memory leak I was only loading and > unloading modules lm93, eeprom, pcf8574. > > >>* What your test script is. Which modules are you cycling exactly, in >>which order, at which rate? I'd be happy to do the same on my own >>machines (with different bus and chip drivers) and see if I can >>reproduce the problem. > > I have attached the script. As far as rate, I was trying to force an > oops (which I could do with a previous release) so the only throttling > was system itself. Basically I ran the test sc ript with this shell > snippet: > > while test.i2c.oops > do > : > done > > As I said earlier in the bug report, its not a likely scenario, but > IMHO it is a valid test case, if only if it stresses the registration > deregistration process. On the system I was running this on we have > a program that kicks off about every 30 seconds and runs the sensors > command. I don't think you needed that to produce the memory leak, > but it probably was requried to produce the oops that you guys seemed > to have fixed. > > The test script is fairly simple. It has an internal list of modules > that it loads in one order, and then unloads in the opposite order. > You can pass the arg --modcount=$number to tell it starting from the > back only load and unload $number modules. You can override its > default module list by using --modules=$mod1,...,$modN. I use depmod > to load and unload the modules, if dependent modules are not loaded > they should be loaded (not tested that though). > > >>Once we know in which kernel module the leak is, it shouldn't be too >>hard to find out where the leak is exactly. There aren't that many >>memory allocations in there. >> >>BTW, thanks a lot for reporting. > > Not a problem. Thanks for looking into this. One of these days I'll > get my head around the I2C and lm_sensors architecture in the kernel, > and maybe I can send you patches instead (-; > > Cheers...james
