Re: [U-Boot] Hash problem...
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
[U-Boot] Hash problem...
I've stumbled across a problem in U-boot 2010.12's hashing algorithm. In my particular case the size of the has table is 347 (due to my default environment being 2258 bytes long as reported on entry to himport_r), and I have in my envrironment the variable "ramdiskimage" as well as "preboot"; part of my startup is to do some housecleaning then delete preboot so its only done once. But when I load u-boot with an empty environemnt environment, I see the following problem: ... => printenv ramdiskimage=rootfs.ext2.gz.uboot => echo $ramdiskimage => setenv ramdiskimage=rootfs.ext2.gz.uboot => printenv ... ramdiskimage=rootfs.ext2.gz.uboot ramdiskimage=rootfs.ext2.gz.uboot ... 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. 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). -- Peter Barada peter.bar...@logicpd.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
