Vikas, On Fri, May 23, 2014 at 5:14 AM, Vikas Sajjan <vikas.sajjan@xxxxxxxxxxx> wrote: > Hi, > > I notice that if CONFIG_SAMSUNG_PM_CHECK is enabled, we get a crash in > function "crc32_le(), as below. PM_CHECK is nowhere near working in upstream. ...or at least it wasn't when I last checked in 3.8 and I can't imagine that someone has fixed everything needed to make it work. My best guess (without digging in detail) as to your particular crash would be missing kmap_atomic calls. The old code would just assume that all physical memory was accessible and cram though it. On modern systems this just isn't true. Note that assuming you're on a 2GB system you may be able to hack around this particular crash temporarily by using a 1G/3G split (VMSPLIT_1G). If you are serious about getting pm_check working upstream you should check out the version in ChromeOS 3.8, clean it up, and land it. A few notes about that, though: 1. In order to get PM_CHECK working on today's modern kernels, you'll need to introduce "suspend volatile" like we did in Chrome OS. This is used to mark areas of memory that shouldn't be checked (because they change between the two calls pm check). These markings need to go in generic (non-samsung) code. 2. In order to have any chance of getting upstream to accept all of the suspend volatile markings, you'll probably need to make pm_check a generic kernel feature and not one specific to Samsung. 3. You can ignore the "bitfix" stuff in the ChromeOS tree. There's pretty much zero chance upstream would want this IMHO. If they want it it could always be tacked on later. I'm happy to answer more questions about pm check, so just let me know. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |