Dear Peter Barada, In message <4d34c85e.4030...@logicpd.com> you wrote: > > After spending an entire day digging into the hash using GDB/BDI on my > ARM board, I've findally figured out that the hash key of "ramdiskimage" > and "preboot" are the same modulus 347, and this is problematic because > on the initial hash import, preboot is placed into the hash first (at > idx 190 since the table is sorted), and then ramdiskimage collides with > preboot causing the 2nd probe (at idx 191) to occur which works fine. > Unfortunately as part of the housecleaning, preboot is deleted and the > environemnt saved. The delete of preboot removes entry at idx 190 and > the next lookup of ramdiskimage sees that idx 190 is empty and believes > that the ramdiskimage is not in the table ionstead of rehashing to find > it at idx 191.
Thanks for debugging this. > The hash delete code is in error; instead of just removing the deleted > key, it should instead allocate a new hashtable, hash all the keys into > the new table except for the deleted key and then reclaim the old table > (and deleted key). Can you please come up with a patch? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "Wagner's music is better than it sounds." - Mark Twain _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot