Re: [PATCH 2/2] sp5100_tco: Write back the original value to reserved bits, instead of zero
2013/1/31 Wim Van Sebroeck : > Hi, > >> In case of SP5100 or SB7x0 chipsets, the sp5100_tco module writes zero to >> reserved bits. The module, however, shouldn't depend on specific default >> value, and should perform a read-merge-write operation for the reserved >> bits. >> >> This patch makes the sp5100_tco module perform a read-merge-write operation >> on all the chipset (sp5100, sb7x0, sb8x0 or later). >> >> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43176 >> Signed-off-by: Takahisa Tanaka > > Added to linux-watchdog-next. Thanks Wim! Kind regards, Takahisa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] sp5100_tco: Write back the original value to reserved bits, instead of zero
2013/1/31 Wim Van Sebroeck w...@iguana.be: Hi, In case of SP5100 or SB7x0 chipsets, the sp5100_tco module writes zero to reserved bits. The module, however, shouldn't depend on specific default value, and should perform a read-merge-write operation for the reserved bits. This patch makes the sp5100_tco module perform a read-merge-write operation on all the chipset (sp5100, sb7x0, sb8x0 or later). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43176 Signed-off-by: Takahisa Tanaka mc74h...@gmail.com Added to linux-watchdog-next. Thanks Wim! Kind regards, Takahisa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Quotaon livelock
Hi lkml, Enabling FS quotas can take up to several minutes to finish and depends on other users disk activity. This makes it a livelock (as it can be finished anyway). The problem described at: http://bugzilla.kernel.org/show_bug.cgi?id=9520 Yes, if we need to enable quotas once in the system start - no problem. But if we have to disable/enable it periodically - this become a nightmare. Please don't advice to use edquota or so (quotactl(Q_SETQUOTA...) based things). What if it's really needed to use quotactl(Q_QUOTAOFF...)/quotactl(Q_QUOTAON...) The problem is at fs/dquot.c:add_dquot_ref() It's restarting to loop over the inodes list once it inits quota on an inode. And this happens over and over if something is modifying inodes list during quotas enabling. It looks like the action must take some time depending on FS size, but not on other users disk activity... Any advices how the algorithm at fs/dquot.c:add_dquot_ref() can be enhanced? Thanks Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Quotaon livelock
Hi lkml, Enabling FS quotas can take up to several minutes to finish and depends on other users disk activity. This makes it a livelock (as it can be finished anyway). The problem described at: http://bugzilla.kernel.org/show_bug.cgi?id=9520 Yes, if we need to enable quotas once in the system start - no problem. But if we have to disable/enable it periodically - this become a nightmare. Please don't advice to use edquota or so (quotactl(Q_SETQUOTA...) based things). What if it's really needed to use quotactl(Q_QUOTAOFF...)/quotactl(Q_QUOTAON...) The problem is at fs/dquot.c:add_dquot_ref() It's restarting to loop over the inodes list once it inits quota on an inode. And this happens over and over if something is modifying inodes list during quotas enabling. It looks like the action must take some time depending on FS size, but not on other users disk activity... Any advices how the algorithm at fs/dquot.c:add_dquot_ref() can be enhanced? Thanks Nick -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
