Re: ACPI errors with 3.7-rc3
Carlos, did you try this patch? https://bugzilla.kernel.org/attachment.cgi?id=73510 On Sat, Jan 26, 2013 at 5:39 PM, Carlos R. Mafra wrote: > On Sat, 26 Jan 2013 at 14:23:12 +0100, Rafael J. Wysocki wrote: >> On Saturday, January 26, 2013 12:23:37 PM Carlos R. Mafra wrote: >> > On Thu, 8 Nov 2012 at 5:47:15 +0100, Greg KH wrote: >> > > On Wed, Nov 07, 2012 at 10:49:40PM +0100, Rafael J. Wysocki wrote: >> > > > On Tuesday, November 06, 2012 01:48:26 PM Greg KH wrote: >> > > > > On Tue, Nov 06, 2012 at 04:42:24PM +0400, Azat Khuzhin wrote: >> > > > > > I'v also have such errors on my macbook pro. >> > > > > > >> > > > > > $ dmesg | tail >> > > > > > [17056.008564] ACPI Error: Method parse/execution failed >> > > > > > [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88026547ea10), AE_TIME >> > > > > > (20120711/psparse-536) >> > > > > > [17056.011194] ACPI Error: Method parse/execution failed >> > > > > > [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME >> > > > > > (20120711/psparse-536) >> > > > > > [17056.013793] ACPI Error: Method parse/execution failed >> > > > > > [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME >> > > > > > (20120711/psparse-536) >> > > > > > [17056.016383] ACPI Exception: AE_TIME, Evaluating _BST >> > > > > > (20120711/battery-464) >> > > > > > [17056.511373] ACPI: EC: input buffer is not empty, aborting >> > > > > > transaction >> > > > > > [17056.512672] ACPI Exception: AE_TIME, Returned by Handler for >> > > > > > [EmbeddedControl] (20120711/evregion-501) >> > > > > > [17056.515256] ACPI Error: Method parse/execution failed >> > > > > > [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88026547ea10), AE_TIME >> > > > > > (20120711/psparse-536) >> > > > > > [17056.517886] ACPI Error: Method parse/execution failed >> > > > > > [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME >> > > > > > (20120711/psparse-536) >> > > > > > [17056.520479] ACPI Error: Method parse/execution failed >> > > > > > [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME >> > > > > > (20120711/psparse-536) >> > > > > > [17056.523070] ACPI Exception: AE_TIME, Evaluating _BST >> > > > > > (20120711/battery-464) >> > > > > >> > > > > I'm seeing this again right now. I'm wondering if it's because I'm >> > > > > running on battery power at the moment: >> > > > > >> > > > > [41694.309264] ACPI Exception: AE_TIME, Returned by Handler for >> > > > > [EmbeddedControl] (20120913/evregion-501) >> > > > > [41694.309282] ACPI Error: Method parse/execution failed >> > > > > [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88045cc64618), AE_TIME >> > > > > (20120913/psparse-536) >> > > > > [41694.309300] ACPI Error: Method parse/execution failed >> > > > > [\_SB_.BAT0.UBST] (Node 88045cc64988), AE_TIME >> > > > > (20120913/psparse-536) >> > > > > [41694.309310] ACPI Error: Method parse/execution failed >> > > > > [\_SB_.BAT0._BST] (Node 88045cc648c0), AE_TIME >> > > > > (20120913/psparse-536) >> > > > > [41694.309324] ACPI Exception: AE_TIME, Evaluating _BST >> > > > > (20120913/battery-464) >> > > > > [41694.809093] ACPI: EC: input buffer is not empty, aborting >> > > > > transaction >> > > > > >> > > > > ec_storm_threshold is still set to 8 in /sys/module/acpi/parameters/ >> > > > > so that's >> > > > > not the issue here. >> > > > > >> > > > > > And also loadavg is too high ~ 10 >> > > > > > While there is no process that load CPU up to 100% or like that. >> > > > > > I think that this because of processes that is done in kernel >> > > > > > space. >> > > > > > (basically that one who write such errors) >> > > > > > >> > > > > > $ uname -a >> > > > > > Linux macbook-pro-sq 3.6.5macbook-pro-custom-v0.1 #4 SMP Sun Nov 4 >> >
western digital caviar black. EXT4-fs error
Recently I update my HDD on desktop machine, and bought WD Caviar Black. But after I format & copy information to it (using dd), and fix partitions size: I have next errors in kern.log: Aug 28 01:49:03 home-spb kernel: [183245.030897] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 3675, 32254 clusters in bitmap, 32258 in gd Aug 28 01:49:03 home-spb kernel: [183245.030956] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 4181, 32254 clusters in bitmap, 32258 in gd Aug 28 01:49:03 home-spb kernel: [183245.030980] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 2600, 32254 clusters in bitmap, 32258 in gd Aug 28 01:49:03 home-spb kernel: [183245.061866] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 9305, 32254 clusters in bitmap, 32258 in gd Aug 28 01:49:03 home-spb kernel: [183245.061892] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 8230, 32254 clusters in bitmap, 32258 in gd Aug 28 01:49:40 home-spb kernel: [183281.733813] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 2477, 32254 clusters in bitmap, 32258 in gd Aug 28 01:49:40 home-spb kernel: [183281.743131] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 28 01:50:13 home-spb kernel: [183314.898637] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 3139, 32254 clusters in bitmap, 32258 in gd Aug 28 01:50:58 home-spb kernel: [183359.783544] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 4061, 32254 clusters in bitmap, 32258 in gd Aug 28 01:50:58 home-spb kernel: [183359.783577] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 8166, 32254 clusters in bitmap, 32258 in gd Aug 28 01:51:08 home-spb kernel: [183369.757927] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 8171, 32254 clusters in bitmap, 32258 in gd Aug 28 16:06:54 home-spb kernel: [234584.906721] EXT4-fs (sdc2): error count: 26 Aug 28 16:06:54 home-spb kernel: [234584.906725] EXT4-fs (sdc2): initial error at 1346069075: ext4_mb_generate_buddy:739 Aug 28 16:06:54 home-spb kernel: [234584.906727] EXT4-fs (sdc2): last error at 1346104268: ext4_mb_generate_buddy:739 One time, machine rebooted (not manually), when I turn it on, it runs fsck on /dev/sdc2 and fix some errors and some files are missing on /dev/sdc2 I'v check /dev/sdc2 for badblocks, it doesn't have it ( using e2fsck -c /dev/sdc2 ) Here is the output of fsck http://pastebin.com/D5LmLVBY What else I can do to understand what's wrong here? BTW for /dev/sdc1 no message like that, in kern.log Linux version: 3.3.0 Distributive: Debian wheezy -- Azat Khuzhin -- 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: western digital caviar black. EXT4-fs error
I'v also post question here http://serverfault.com/questions/423565/western-digital-caviar-black-ext4-fs-error On Sat, Sep 1, 2012 at 11:48 PM, Azat Khuzhin wrote: > Recently I update my HDD on desktop machine, and bought WD Caviar Black. > But after I format & copy information to it (using dd), and fix > partitions size: I have next errors in kern.log: > > Aug 28 01:49:03 home-spb kernel: [183245.030897] EXT4-fs error (device > sdc2): ext4_mb_generate_buddy:739: group 3675, 32254 clusters in > bitmap, 32258 in gd > Aug 28 01:49:03 home-spb kernel: [183245.030956] EXT4-fs error (device > sdc2): ext4_mb_generate_buddy:739: group 4181, 32254 clusters in > bitmap, 32258 in gd > Aug 28 01:49:03 home-spb kernel: [183245.030980] EXT4-fs error (device > sdc2): ext4_mb_generate_buddy:739: group 2600, 32254 clusters in > bitmap, 32258 in gd > Aug 28 01:49:03 home-spb kernel: [183245.061866] EXT4-fs error (device > sdc2): ext4_mb_generate_buddy:739: group 9305, 32254 clusters in > bitmap, 32258 in gd > Aug 28 01:49:03 home-spb kernel: [183245.061892] EXT4-fs error (device > sdc2): ext4_mb_generate_buddy:739: group 8230, 32254 clusters in > bitmap, 32258 in gd > Aug 28 01:49:40 home-spb kernel: [183281.733813] EXT4-fs error (device > sdc2): ext4_mb_generate_buddy:739: group 2477, 32254 clusters in > bitmap, 32258 in gd > Aug 28 01:49:40 home-spb kernel: [183281.743131] JBD2: Spotted dirty > metadata buffer (dev = sdc2, blocknr = 0). There's a risk of > filesystem corruption in case of system crash. > Aug 28 01:50:13 home-spb kernel: [183314.898637] EXT4-fs error (device > sdc2): ext4_mb_generate_buddy:739: group 3139, 32254 clusters in > bitmap, 32258 in gd > Aug 28 01:50:58 home-spb kernel: [183359.783544] EXT4-fs error (device > sdc2): ext4_mb_generate_buddy:739: group 4061, 32254 clusters in > bitmap, 32258 in gd > Aug 28 01:50:58 home-spb kernel: [183359.783577] EXT4-fs error (device > sdc2): ext4_mb_generate_buddy:739: group 8166, 32254 clusters in > bitmap, 32258 in gd > Aug 28 01:51:08 home-spb kernel: [183369.757927] EXT4-fs error (device > sdc2): ext4_mb_generate_buddy:739: group 8171, 32254 clusters in > bitmap, 32258 in gd > Aug 28 16:06:54 home-spb kernel: [234584.906721] EXT4-fs (sdc2): error count: > 26 > Aug 28 16:06:54 home-spb kernel: [234584.906725] EXT4-fs (sdc2): > initial error at 1346069075: ext4_mb_generate_buddy:739 > Aug 28 16:06:54 home-spb kernel: [234584.906727] EXT4-fs (sdc2): last > error at 1346104268: ext4_mb_generate_buddy:739 > > One time, machine rebooted (not manually), when I turn it on, it runs > fsck on /dev/sdc2 and fix some errors and some files are missing on > /dev/sdc2 > > I'v check /dev/sdc2 for badblocks, it doesn't have it ( using e2fsck > -c /dev/sdc2 ) > Here is the output of fsck http://pastebin.com/D5LmLVBY > > What else I can do to understand what's wrong here? > > BTW for /dev/sdc1 no message like that, in kern.log > > Linux version: 3.3.0 > Distributive: Debian wheezy > > -- > Azat Khuzhin -- Azat Khuzhin -- 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: western digital caviar black. EXT4-fs error
Anybody? On Sat, Sep 1, 2012 at 11:53 PM, Azat Khuzhin wrote: > I'v also post question here > > http://serverfault.com/questions/423565/western-digital-caviar-black-ext4-fs-error > > On Sat, Sep 1, 2012 at 11:48 PM, Azat Khuzhin wrote: >> Recently I update my HDD on desktop machine, and bought WD Caviar Black. >> But after I format & copy information to it (using dd), and fix >> partitions size: I have next errors in kern.log: >> >> Aug 28 01:49:03 home-spb kernel: [183245.030897] EXT4-fs error (device >> sdc2): ext4_mb_generate_buddy:739: group 3675, 32254 clusters in >> bitmap, 32258 in gd >> Aug 28 01:49:03 home-spb kernel: [183245.030956] EXT4-fs error (device >> sdc2): ext4_mb_generate_buddy:739: group 4181, 32254 clusters in >> bitmap, 32258 in gd >> Aug 28 01:49:03 home-spb kernel: [183245.030980] EXT4-fs error (device >> sdc2): ext4_mb_generate_buddy:739: group 2600, 32254 clusters in >> bitmap, 32258 in gd >> Aug 28 01:49:03 home-spb kernel: [183245.061866] EXT4-fs error (device >> sdc2): ext4_mb_generate_buddy:739: group 9305, 32254 clusters in >> bitmap, 32258 in gd >> Aug 28 01:49:03 home-spb kernel: [183245.061892] EXT4-fs error (device >> sdc2): ext4_mb_generate_buddy:739: group 8230, 32254 clusters in >> bitmap, 32258 in gd >> Aug 28 01:49:40 home-spb kernel: [183281.733813] EXT4-fs error (device >> sdc2): ext4_mb_generate_buddy:739: group 2477, 32254 clusters in >> bitmap, 32258 in gd >> Aug 28 01:49:40 home-spb kernel: [183281.743131] JBD2: Spotted dirty >> metadata buffer (dev = sdc2, blocknr = 0). There's a risk of >> filesystem corruption in case of system crash. >> Aug 28 01:50:13 home-spb kernel: [183314.898637] EXT4-fs error (device >> sdc2): ext4_mb_generate_buddy:739: group 3139, 32254 clusters in >> bitmap, 32258 in gd >> Aug 28 01:50:58 home-spb kernel: [183359.783544] EXT4-fs error (device >> sdc2): ext4_mb_generate_buddy:739: group 4061, 32254 clusters in >> bitmap, 32258 in gd >> Aug 28 01:50:58 home-spb kernel: [183359.783577] EXT4-fs error (device >> sdc2): ext4_mb_generate_buddy:739: group 8166, 32254 clusters in >> bitmap, 32258 in gd >> Aug 28 01:51:08 home-spb kernel: [183369.757927] EXT4-fs error (device >> sdc2): ext4_mb_generate_buddy:739: group 8171, 32254 clusters in >> bitmap, 32258 in gd >> Aug 28 16:06:54 home-spb kernel: [234584.906721] EXT4-fs (sdc2): error >> count: 26 >> Aug 28 16:06:54 home-spb kernel: [234584.906725] EXT4-fs (sdc2): >> initial error at 1346069075: ext4_mb_generate_buddy:739 >> Aug 28 16:06:54 home-spb kernel: [234584.906727] EXT4-fs (sdc2): last >> error at 1346104268: ext4_mb_generate_buddy:739 >> >> One time, machine rebooted (not manually), when I turn it on, it runs >> fsck on /dev/sdc2 and fix some errors and some files are missing on >> /dev/sdc2 >> >> I'v check /dev/sdc2 for badblocks, it doesn't have it ( using e2fsck >> -c /dev/sdc2 ) >> Here is the output of fsck http://pastebin.com/D5LmLVBY >> >> What else I can do to understand what's wrong here? >> >> BTW for /dev/sdc1 no message like that, in kern.log >> >> Linux version: 3.3.0 >> Distributive: Debian wheezy >> >> -- >> Azat Khuzhin > > > > -- > Azat Khuzhin -- Azat Khuzhin -- 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: western digital caviar black. EXT4-fs error
Ted, many thanks! I'll try to compile new kernel (maybe 3.4.x) On Tue, Sep 4, 2012 at 7:15 AM, Theodore Ts'o wrote: > On Sat, Sep 01, 2012 at 11:48:17PM +0400, Azat Khuzhin wrote: >> Recently I update my HDD on desktop machine, and bought WD Caviar Black. >> But after I format & copy information to it (using dd), and fix >> partitions size: I have next errors in kern.log: >> >> Aug 28 01:49:03 home-spb kernel: [183245.030897] EXT4-fs error (device >> sdc2): ext4_mb_generate_buddy:739: group 3675, 32254 clusters in >> bitmap, 32258 in gd > > Sorry for the delay; you sent this to linux-kernel (and not the > linux-ext4 list). It also took me a while to dig up the relevant fix > from my archives; normally, once a bug has been fixed (as this one > was, on June 7, 2012) I don't worry about it any more. > > The upstream fix is commit b0dd6b70f0fda17ae9762fbb72d98e40a4f66556. > > Note that you are using the 3.3.0 kernel. This is a not long-term > supported kernel, so fixes from upstream are no longer being > backported to it. The official Debian kernel (which tracks the 3.2.x > stable kernel series) has the backported bug fix. So does the 3.4 > long-term stable kernel series, as does the 3.5 kernel or any later > kernel. > > If you don't know how to backport a kernel patch, or even if you do, I > would strongly suggest that you either go back to the Debian standard > kernel for Wheezy, or track the 3.2.x or 3.4.x long-term stable > kernel. (The fix is in v3.2.20 or later, and v3.4.3 or later --- > where those trees are up to v3.2.28, and v3.4.10, respectively.) > Otherwise, you may very well run into some other kernel bug which has > already been fixed upstream, and you'll just waste your time as well > as various other kernel developers. > > Regards, > > - Ted -- Azat Khuzhin -- 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: high load average in linux-3.6
Can anybody say is this fixed or not? Or maybe you need more information? Thanks. On Fri, Aug 17, 2012 at 1:10 AM, Azat Khuzhin wrote: > Hi all. > > After updating to linux-v3.6-rc1-315-g3c31a6e I noticed that load avg > is too high for "current" CPU usage & IO activity > > Just after starting, I see next things: > 1) I'v kill all processes that I "can" > iostat_min_tasks - http://pastebin.com/T59xKEy4 > ps_min_tasks - http://pastebin.com/b7zVy6up > w_min_tasks - http://pastebin.com/UFFsncSn > > 2) After I started some processes/services (kde,nginx,mysql ...) > iostat_with_graph - http://pastebin.com/bejGneGv > ps_with_graph - http://pastebin.com/Nt9g0ynW > w_with_graph - http://pastebin.com/pYuUbyVY > ( graph - with DE ) > > When I 3.3.0 I did not notice such situation. > > I'v trying to set kernel cmd line to "i915.i915_enable_rc6=1 > i915.i915_enable_fbc=1 i915.lvds_downclock=1 drm.vblankoffdelay=1" > like here https://bugs.archlinux.org/task/29850 > But this doesn't helps. > > -- > Azat Khuzhin -- Azat Khuzhin -- 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: western digital caviar black. EXT4-fs error
Ted, Thanks! It fix my problem. On Wed, Sep 5, 2012 at 12:37 AM, Azat Khuzhin wrote: > Ted, many thanks! > I'll try to compile new kernel (maybe 3.4.x) > > On Tue, Sep 4, 2012 at 7:15 AM, Theodore Ts'o wrote: >> On Sat, Sep 01, 2012 at 11:48:17PM +0400, Azat Khuzhin wrote: >>> Recently I update my HDD on desktop machine, and bought WD Caviar Black. >>> But after I format & copy information to it (using dd), and fix >>> partitions size: I have next errors in kern.log: >>> >>> Aug 28 01:49:03 home-spb kernel: [183245.030897] EXT4-fs error (device >>> sdc2): ext4_mb_generate_buddy:739: group 3675, 32254 clusters in >>> bitmap, 32258 in gd >> >> Sorry for the delay; you sent this to linux-kernel (and not the >> linux-ext4 list). It also took me a while to dig up the relevant fix >> from my archives; normally, once a bug has been fixed (as this one >> was, on June 7, 2012) I don't worry about it any more. >> >> The upstream fix is commit b0dd6b70f0fda17ae9762fbb72d98e40a4f66556. >> >> Note that you are using the 3.3.0 kernel. This is a not long-term >> supported kernel, so fixes from upstream are no longer being >> backported to it. The official Debian kernel (which tracks the 3.2.x >> stable kernel series) has the backported bug fix. So does the 3.4 >> long-term stable kernel series, as does the 3.5 kernel or any later >> kernel. >> >> If you don't know how to backport a kernel patch, or even if you do, I >> would strongly suggest that you either go back to the Debian standard >> kernel for Wheezy, or track the 3.2.x or 3.4.x long-term stable >> kernel. (The fix is in v3.2.20 or later, and v3.4.3 or later --- >> where those trees are up to v3.2.28, and v3.4.10, respectively.) >> Otherwise, you may very well run into some other kernel bug which has >> already been fixed upstream, and you'll just waste your time as well >> as various other kernel developers. >> >> Regards, >> >> - Ted > > > > -- > Azat Khuzhin -- Azat Khuzhin -- 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/
[PATCH] ext4: drop unsed reclen variable from ext4_add_dirent_to_inline()
Functions that need in it, already calculate reclen from namelen by themselves: - ext4_find_dest_de() - ext4_insert_dentry() Signed-off-by: Azat Khuzhin --- fs/ext4/inline.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c index d9ecbf1..809f285 100644 --- a/fs/ext4/inline.c +++ b/fs/ext4/inline.c @@ -994,11 +994,9 @@ static int ext4_add_dirent_to_inline(handle_t *handle, struct inode*dir = dentry->d_parent->d_inode; const char *name = dentry->d_name.name; int namelen = dentry->d_name.len; - unsigned short reclen; int err; struct ext4_dir_entry_2 *de; - reclen = EXT4_DIR_REC_LEN(namelen); err = ext4_find_dest_de(dir, inode, iloc->bh, inline_start, inline_size, name, namelen, &de); -- 1.8.4.rc3 -- 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/
[PATCH] Btrfs: cleanup redundant code in __btrfs_close_devices()
Signed-off-by: Azat Khuzhin
---
fs/btrfs/volumes.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 1d1b595..124228e 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -644,7 +644,7 @@ static int __btrfs_close_devices(struct btrfs_fs_devices
*fs_devices)
/* Safe because we are under uuid_mutex */
if (device->name) {
name = rcu_string_strdup(device->name->str, GFP_NOFS);
- BUG_ON(device->name && !name); /* -ENOMEM */
+ BUG_ON(!name); /* -ENOMEM */
rcu_assign_pointer(new_device->name, name);
}
new_device->bdev = NULL;
--
1.7.10.4
--
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] Btrfs: cleanup redundant code in __btrfs_close_devices()
On Mon, Sep 9, 2013 at 7:28 AM, Wang Shilong wrote:
> On 09/08/2013 12:15 AM, Azat Khuzhin wrote:
>>
>> Signed-off-by: Azat Khuzhin
>> ---
>> fs/btrfs/volumes.c |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
>> index 1d1b595..124228e 100644
>> --- a/fs/btrfs/volumes.c
>> +++ b/fs/btrfs/volumes.c
>> @@ -644,7 +644,7 @@ static int __btrfs_close_devices(struct
>> btrfs_fs_devices *fs_devices)
>> /* Safe because we are under uuid_mutex */
>> if (device->name) {
>> name = rcu_string_strdup(device->name->str,
>> GFP_NOFS);
>> - BUG_ON(device->name && !name); /* -ENOMEM */
>> + BUG_ON(!name); /* -ENOMEM *
>
> Nice catch! out of memory should not trigger BUG_ON()..
> Maybe we can handle it gracefully.
Maybe return -ENOMEM ?
>
> Thanks,
> Wang
>
>> rcu_assign_pointer(new_device->name, name);
>> }
>> new_device->bdev = NULL;
>
>
--
Respectfully
Azat Khuzhin
--
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] Btrfs: cleanup redundant code in __btrfs_close_devices()
On Tue, Sep 10, 2013 at 5:15 PM, Wang Shilong wrote:
>> On Mon, Sep 9, 2013 at 7:28 AM, Wang Shilong
>> wrote:
>>> On 09/08/2013 12:15 AM, Azat Khuzhin wrote:
>>>>
>>>> Signed-off-by: Azat Khuzhin
>>>> ---
>>>> fs/btrfs/volumes.c |2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
>>>> index 1d1b595..124228e 100644
>>>> --- a/fs/btrfs/volumes.c
>>>> +++ b/fs/btrfs/volumes.c
>>>> @@ -644,7 +644,7 @@ static int __btrfs_close_devices(struct
>>>> btrfs_fs_devices *fs_devices)
>>>>/* Safe because we are under uuid_mutex */
>>>>if (device->name) {
>>>>name = rcu_string_strdup(device->name->str,
>>>> GFP_NOFS);
>>>> - BUG_ON(device->name && !name); /* -ENOMEM */
>>>> + BUG_ON(!name); /* -ENOMEM *
>>>
>>> Nice catch! out of memory should not trigger BUG_ON()..
>>> Maybe we can handle it gracefully.
>>
>> Maybe return -ENOMEM ?
>
> Yeah, BUG_On is really unfriendly. And here ENOMEM triggers
> BUG_ON() is a lazy approach.
>
> I think we can return -ENOMEM rather than BUG_ON(), the caller can handle
> this.
I will write a patch, when this one will be merged, to avoid conflicts,
and also because the issue that this patch solves is different from BUG_ON().
>
> Thanks,
> Wang
>>
>>>
>>> Thanks,
>>> Wang
>>>
>>>>rcu_assign_pointer(new_device->name, name);
>>>>}
>>>>new_device->bdev = NULL;
>>>
>>>
>>
>>
>>
>> --
>> Respectfully
>> Azat Khuzhin
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Respectfully
Azat Khuzhin
--
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] btrfs: use list_for_each_entry_safe() when delete items
On Tue, Jul 30, 2013 at 7:40 AM, Miao Xie wrote:
> On mon, 29 Jul 2013 11:48:32 +0400, Azat Khuzhin wrote:
>> On Sat, Jul 27, 2013 at 2:12 PM, Azat Khuzhin wrote:
>>> Replace list_for_each_entry() by list_for_each_entry_safe() in
>>> __btrfs_close_devices()
>>>
>>> There is another place that delete items lock_stripe_add(), but there we
>>> don't need safe version, because after deleting we exit from loop.
>>>
>>> Signed-off-by: Azat Khuzhin
>>> ---
>>> fs/btrfs/volumes.c |4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
>>> index 78b8717..1d1b595 100644
>>> --- a/fs/btrfs/volumes.c
>>> +++ b/fs/btrfs/volumes.c
>>> @@ -616,13 +616,13 @@ static void free_device(struct rcu_head *head)
>>>
>>> static int __btrfs_close_devices(struct btrfs_fs_devices *fs_devices)
>>> {
>>> - struct btrfs_device *device;
>>> + struct btrfs_device *device, *next;
>>>
>>> if (--fs_devices->opened > 0)
>>> return 0;
>>>
>>> mutex_lock(&fs_devices->device_list_mutex);
>>> - list_for_each_entry(device, &fs_devices->devices, dev_list) {
>>> + list_for_each_entry_safe(device, next, &fs_devices->devices,
>>> dev_list) {
>>> struct btrfs_device *new_device;
>>> struct rcu_string *name;
>>
>> There is "kfree(device);" at the end of loop, maybe there must "goto
>> again;" after it?
>> (instead of this patch)
Ugh. I was looking into another function!
>
> Your fix is right, we needn't search from the head once again.
>
> The other fix way is:
> call_rcu(&device->rcu, free_device);
> + device = new_device;
> }
> but from the viewpoint of the readability, this way is not so good.
>
> Reviewed-by: Miao Xie
Thanks!
Miao, should I resend patch with you reviewed-by?
>
>>
>>>
>>> --
>>> 1.7.10.4
>>>
>>
>>
>>
>
--
Respectfully
Azat Khuzhin
--
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/
[PATCH] btrfs: use list_for_each_entry_safe() when delete items
Replace list_for_each_entry() by list_for_each_entry_safe() in
__btrfs_close_devices()
list_for_each_entry() {
list_replace_rcu();
call_rcu(); <--We may free the device, if we get next
device by the current one, the page fault
may happen.
}
Signed-off-by: Azat Khuzhin
Reviewed-by: Miao Xie
---
V2: Add some comments from Miao into commit message
fs/btrfs/volumes.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 78b8717..1d1b595 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -616,13 +616,13 @@ static void free_device(struct rcu_head *head)
static int __btrfs_close_devices(struct btrfs_fs_devices *fs_devices)
{
- struct btrfs_device *device;
+ struct btrfs_device *device, *next;
if (--fs_devices->opened > 0)
return 0;
mutex_lock(&fs_devices->device_list_mutex);
- list_for_each_entry(device, &fs_devices->devices, dev_list) {
+ list_for_each_entry_safe(device, next, &fs_devices->devices, dev_list) {
struct btrfs_device *new_device;
struct rcu_string *name;
--
1.7.10.4
--
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: ACPI errors with 3.7-rc3
I tried this patch - https://bugzilla.kernel.org/attachment.cgi?id=73510 from https://bugzilla.kernel.org/show_bug.cgi?id=14733. And I don't see such messages any more. But another problem surfaced - laptop can't resume working after a long time held in suspend, end there is not messages in kern.log about that laptop trying to resume. On Sat, Nov 17, 2012 at 9:40 AM, Robert Hancock wrote: > On 11/09/2012 10:36 AM, Feng Tang wrote: >> >> On Fri, Nov 09, 2012 at 10:30:43PM +0800, Moore, Robert wrote: >>> >>> The ACPI Global Lock is in fact intended to provide exclusion between the >>> BIOS and the OS. >>> Bob >> >> >> Thanks for the info. >> >> And per my check, most of ACPI FW don't implement this lock, say >> after driver probe, the ec->global_lock will be 0. > > > The DSDT is supposed to define the _GLK control method on the EC if the BIOS > needs to perform its own access which may conflict with the OS usage. If it > doesn't, then it should be the case that either the BIOS doesn't touch the > EC itself or it uses a separate interface that doesn't cause conflicts with > what the OS is doing. > >> >> - Feng >> >>> >>> >>>> -Original Message- >>>> From: Tang, Feng >>>> Sent: Friday, November 09, 2012 1:29 AM >>>> To: Rafael J. Wysocki >>>> Cc: Greg KH; Azat Khuzhin; linux-a...@vger.kernel.org; Linux Kernel >>>> Mailing List; Zheng, Lv; Len Brown; Moore, Robert >>>> Subject: Re: ACPI errors with 3.7-rc3 >>>> >>>> On Thu, Nov 08, 2012 at 05:49:40AM +0800, Rafael J. Wysocki wrote: >>>>> >>>>> On Tuesday, November 06, 2012 01:48:26 PM Greg KH wrote: >>>>>> >>>>>> On Tue, Nov 06, 2012 at 04:42:24PM +0400, Azat Khuzhin wrote: >>>>>>> >>>>>>> I'v also have such errors on my macbook pro. >>>>>>> >>>>>>> $ dmesg | tail >>>>>>> [17056.008564] ACPI Error: Method parse/execution failed >>>>>>> [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88026547ea10), AE_TIME >>>>>>> (20120711/psparse-536) >>>>>>> [17056.011194] ACPI Error: Method parse/execution failed >>>>>>> [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME >>>>>>> (20120711/psparse-536) >>>>>>> [17056.013793] ACPI Error: Method parse/execution failed >>>>>>> [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME >>>>>>> (20120711/psparse-536) >>>>>>> [17056.016383] ACPI Exception: AE_TIME, Evaluating _BST >>>>>>> (20120711/battery-464) [17056.511373] ACPI: EC: input buffer is >>>>>>> not empty, aborting transaction [17056.512672] ACPI Exception: >>>>>>> AE_TIME, Returned by Handler for [EmbeddedControl] >>>>>>> (20120711/evregion-501) [17056.515256] ACPI Error: Method >>>>>>> parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node >>>>>>> 88026547ea10), AE_TIME >>>>>>> (20120711/psparse-536) >>>>>>> [17056.517886] ACPI Error: Method parse/execution failed >>>>>>> [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME >>>>>>> (20120711/psparse-536) >>>>>>> [17056.520479] ACPI Error: Method parse/execution failed >>>>>>> [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME >>>>>>> (20120711/psparse-536) >>>>>>> [17056.523070] ACPI Exception: AE_TIME, Evaluating _BST >>>>>>> (20120711/battery-464) >>>>>> >>>>>> >>>>>> I'm seeing this again right now. I'm wondering if it's because I'm >>>>>> running on battery power at the moment: >>>>>> >>>>>> [41694.309264] ACPI Exception: AE_TIME, Returned by Handler for >>>>>> [EmbeddedControl] (20120913/evregion-501) [41694.309282] ACPI Error: >>>>>> Method parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node >>>>>> 88045cc64618), AE_TIME (20120913/psparse-536) [41694.309300] >>>>>> ACPI Error: Method parse/execution failed [\_SB_.BAT0.UBST] (Node >>>>>> 88045cc64988), AE_TIME (20120913/psparse-536) [41694.309310] >>>>>> ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] (Node >>>>>> 880
Re: ACPI errors with 3.7-rc3
Update: laptop don't resume working not only after a long time held in suspend, but also after a short period of time for example 3 minutes. As for a long time - it about 24-36 hours. On Sun, Dec 2, 2012 at 12:59 AM, Azat Khuzhin wrote: > I tried this patch - https://bugzilla.kernel.org/attachment.cgi?id=73510 > from https://bugzilla.kernel.org/show_bug.cgi?id=14733. > > And I don't see such messages any more. > But another problem surfaced - laptop can't resume working after a > long time held in suspend, > end there is not messages in kern.log about that laptop trying to resume. > > On Sat, Nov 17, 2012 at 9:40 AM, Robert Hancock wrote: >> On 11/09/2012 10:36 AM, Feng Tang wrote: >>> >>> On Fri, Nov 09, 2012 at 10:30:43PM +0800, Moore, Robert wrote: >>>> >>>> The ACPI Global Lock is in fact intended to provide exclusion between the >>>> BIOS and the OS. >>>> Bob >>> >>> >>> Thanks for the info. >>> >>> And per my check, most of ACPI FW don't implement this lock, say >>> after driver probe, the ec->global_lock will be 0. >> >> >> The DSDT is supposed to define the _GLK control method on the EC if the BIOS >> needs to perform its own access which may conflict with the OS usage. If it >> doesn't, then it should be the case that either the BIOS doesn't touch the >> EC itself or it uses a separate interface that doesn't cause conflicts with >> what the OS is doing. >> >>> >>> - Feng >>> >>>> >>>> >>>>> -Original Message- >>>>> From: Tang, Feng >>>>> Sent: Friday, November 09, 2012 1:29 AM >>>>> To: Rafael J. Wysocki >>>>> Cc: Greg KH; Azat Khuzhin; linux-a...@vger.kernel.org; Linux Kernel >>>>> Mailing List; Zheng, Lv; Len Brown; Moore, Robert >>>>> Subject: Re: ACPI errors with 3.7-rc3 >>>>> >>>>> On Thu, Nov 08, 2012 at 05:49:40AM +0800, Rafael J. Wysocki wrote: >>>>>> >>>>>> On Tuesday, November 06, 2012 01:48:26 PM Greg KH wrote: >>>>>>> >>>>>>> On Tue, Nov 06, 2012 at 04:42:24PM +0400, Azat Khuzhin wrote: >>>>>>>> >>>>>>>> I'v also have such errors on my macbook pro. >>>>>>>> >>>>>>>> $ dmesg | tail >>>>>>>> [17056.008564] ACPI Error: Method parse/execution failed >>>>>>>> [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88026547ea10), AE_TIME >>>>>>>> (20120711/psparse-536) >>>>>>>> [17056.011194] ACPI Error: Method parse/execution failed >>>>>>>> [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME >>>>>>>> (20120711/psparse-536) >>>>>>>> [17056.013793] ACPI Error: Method parse/execution failed >>>>>>>> [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME >>>>>>>> (20120711/psparse-536) >>>>>>>> [17056.016383] ACPI Exception: AE_TIME, Evaluating _BST >>>>>>>> (20120711/battery-464) [17056.511373] ACPI: EC: input buffer is >>>>>>>> not empty, aborting transaction [17056.512672] ACPI Exception: >>>>>>>> AE_TIME, Returned by Handler for [EmbeddedControl] >>>>>>>> (20120711/evregion-501) [17056.515256] ACPI Error: Method >>>>>>>> parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node >>>>>>>> 88026547ea10), AE_TIME >>>>>>>> (20120711/psparse-536) >>>>>>>> [17056.517886] ACPI Error: Method parse/execution failed >>>>>>>> [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME >>>>>>>> (20120711/psparse-536) >>>>>>>> [17056.520479] ACPI Error: Method parse/execution failed >>>>>>>> [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME >>>>>>>> (20120711/psparse-536) >>>>>>>> [17056.523070] ACPI Exception: AE_TIME, Evaluating _BST >>>>>>>> (20120711/battery-464) >>>>>>> >>>>>>> >>>>>>> I'm seeing this again right now. I'm wondering if it's because I'm >>>>>>> running on battery power at the moment: >>>>>>> >>>>>>> [41694.309264] ACPI Exception: AE_TIME, Returned by Handl
Re: ACPI errors with 3.7-rc3
Robert, thanks. I have such message again, and load avg up to 30, and the increase up to 40, after to 50. I found this https://bugzilla.kernel.org/show_bug.cgi?id=14733 and I after I compile kernel with this patch write message about results. Also I want to note that after I suspend laptop to ~20-15 minutes and resume, it works fine. And no such spam in log. But after this hack if open lid, laptop not exit from suspend mode, for exit from it, I must manually press key on keyboard. I try to restart acpid, laptop-mode but nothing of this helped me. $ dmesg | tail -n20 [122582.074256] ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME (20120711/psparse-536) [122582.076668] ACPI Exception: AE_TIME, Evaluating _BST (20120711/battery-464) [122582.572501] ACPI: EC: input buffer is not empty, aborting transaction [122582.573710] ACPI Exception: AE_TIME, Returned by Handler for [EmbeddedControl] (20120711/evregion-501) [122582.576121] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88026547ea10), AE_TIME (20120711/psparse-536) [122582.578548] ACPI Error: Method parse/execution failed [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME (20120711/psparse-536) [122582.580964] ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME (20120711/psparse-536) [122582.583378] ACPI Exception: AE_TIME, Evaluating _BST (20120711/battery-464) [122583.079191] ACPI: EC: input buffer is not empty, aborting transaction [122583.080488] ACPI Exception: AE_TIME, Returned by Handler for [EmbeddedControl] (20120711/evregion-501) [122583.083073] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88026547ea10), AE_TIME (20120711/psparse-536) [122583.085671] ACPI Error: Method parse/execution failed [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME (20120711/psparse-536) [122583.088264] ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME (20120711/psparse-536) [122583.090893] ACPI Exception: AE_TIME, Evaluating _BST (20120711/battery-464) [122583.585891] ACPI: EC: input buffer is not empty, aborting transaction [122583.587100] ACPI Exception: AE_TIME, Returned by Handler for [EmbeddedControl] (20120711/evregion-501) [122583.589578] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88026547ea10), AE_TIME (20120711/psparse-536) [122583.592003] ACPI Error: Method parse/execution failed [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME (20120711/psparse-536) [122583.594419] ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME (20120711/psparse-536) [122583.596859] ACPI Exception: AE_TIME, Evaluating _BST (20120711/battery-464) On Tue, Nov 13, 2012 at 4:41 AM, Moore, Robert wrote: > Actually, it is not the address of the global lock, the FACS contains the > actual global lock: > > From acpi5.0 spec: > > ROM BIOS. The Global Lock is a 32-bit (DWORD) value in read/write memory > located within the FACS and is accessed and updated by both the OS > environment and the SMI environment in a defined manner to provide an > exclusive lock. Note: this is not a pointer to the Global Lock, it is the > actual memory location of the lock. The FACS and Global Lock may be located > anywhere in physical memory. > > > > >> -Original Message- >> From: a3at.m...@gmail.com [mailto:a3at.m...@gmail.com] On Behalf Of Azat >> Khuzhin >> Sent: Sunday, November 11, 2012 2:01 AM >> To: Moore, Robert >> Cc: Tang, Feng; Rafael J. Wysocki; Greg KH; linux-a...@vger.kernel.org; >> Linux Kernel Mailing List; Zheng, Lv; Len Brown >> Subject: Re: ACPI errors with 3.7-rc3 >> >> Robert, >> >> You say that FACS table contains the address of the global lock. >> But in my case https://gist.github.com/4037687 it seems to be empty, so >> this means that my laptop don't have global lock? >> >> On Fri, Nov 9, 2012 at 8:45 PM, Moore, Robert >> wrote: >> >> And per my check, most of ACPI FW don't implement this lock, say >> >> after driver probe, the ec->global_lock will be 0 >> > >> > Take a look at the FACS table, it contains the address of the global >> lock. >> > >> > I believe that the ACPI specification requires that the global lock be >> present. >> > >> > >> > >> >> -Original Message- >> >> From: Tang, Feng >> >> Sent: Friday, November 09, 2012 8:36 AM >> >> To: Moore, Robert >> >> Cc: Rafael J. Wysocki; Greg KH; Azat Khuzhin; >> >> linux-a...@vger.kernel.org; Linux Kernel Mailing List; Zheng, Lv; Len >> >> Brown >> >> Subject: Re: ACPI erro
Re: ACPI errors with 3.7-rc3
I'v also have such errors on my macbook pro. $ dmesg | tail [17056.008564] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88026547ea10), AE_TIME (20120711/psparse-536) [17056.011194] ACPI Error: Method parse/execution failed [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME (20120711/psparse-536) [17056.013793] ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME (20120711/psparse-536) [17056.016383] ACPI Exception: AE_TIME, Evaluating _BST (20120711/battery-464) [17056.511373] ACPI: EC: input buffer is not empty, aborting transaction [17056.512672] ACPI Exception: AE_TIME, Returned by Handler for [EmbeddedControl] (20120711/evregion-501) [17056.515256] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88026547ea10), AE_TIME (20120711/psparse-536) [17056.517886] ACPI Error: Method parse/execution failed [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME (20120711/psparse-536) [17056.520479] ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME (20120711/psparse-536) [17056.523070] ACPI Exception: AE_TIME, Evaluating _BST (20120711/battery-464) And also loadavg is too high ~ 10 While there is no process that load CPU up to 100% or like that. I think that this because of processes that is done in kernel space. (basically that one who write such errors) $ uname -a Linux macbook-pro-sq 3.6.5macbook-pro-custom-v0.1 #4 SMP Sun Nov 4 12:39:03 UTC 2012 x86_64 GNU/Linux On Wed, Oct 31, 2012 at 9:33 PM, Greg KH wrote: > On Wed, Oct 31, 2012 at 10:11:21AM +0100, Rafael J. Wysocki wrote: >> Hi Greg, >> >> On Tuesday, October 30, 2012 06:45:27 PM Greg KH wrote: >> > Hi Len and Rafael, >> > >> > With 3.7-rc3, I'm seeing a constant stream of these errors in the kernel >> > log for my MacBook Pro: >> > >> > [30443.430133] ACPI: EC: input buffer is not empty, aborting transaction >> > [30443.430145] ACPI Exception: AE_TIME, Returned by Handler for >> > [EmbeddedControl] (20120913/evregion-501) >> > [30443.430162] ACPI Error: Method parse/execution failed >> > [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88045cc64618), AE_TIME >> > (20120913/psparse-536) >> > [30443.430179] ACPI Error: Method parse/execution failed [\_SB_.BAT0.UBST] >> > (Node 88045cc64988), AE_TIME (20120913/psparse-536) >> > [30443.430188] ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] >> > (Node 88045cc648c0), AE_TIME (20120913/psparse-536) >> > [30443.430202] ACPI Exception: AE_TIME, Evaluating _BST >> > (20120913/battery-464) >> > >> > They never showed up before in 3.7-rc2. >> > >> > Anything I should try out to resolve this? >> >> Well, there are the following two post-3.6 EC-related commits: >> >> commit 67bfa9b60bd689601554526d144b21d529f78a09 >> Author: Feng Tang >> Date: Fri Sep 28 15:22:01 2012 +0800 >> >> ACPI: EC: Add a quirk for CLEVO M720T/M730T laptop >> >> commit a520d52e99b14ba7db135e916348f12f2a6e09be >> Author: Feng Tang >> Date: Fri Sep 28 15:22:00 2012 +0800 >> >> ACPI: EC: Make the GPE storm threshold a module parameter >> >> Can you please check if reverting the second one helps? > > That last one seems like it would be it, if the module parameter got > changed. And now I can't duplicate it at all, 3.7-rc3 works fine. Ick, > sorry for the noise, I don't know what happened. If I see the above > errors again, I'll let you know, and I'll also check the ec module > parameter first to ensure it didn't change from the default of 8. > > thanks, > > greg k-h > -- > 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/ -- Azat Khuzhin -- 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: ACPI errors with 3.7-rc3
When this messages appears, I was running from AC, not from battery. On Tue, Nov 6, 2012 at 4:48 PM, Greg KH wrote: > On Tue, Nov 06, 2012 at 04:42:24PM +0400, Azat Khuzhin wrote: >> I'v also have such errors on my macbook pro. >> >> $ dmesg | tail >> [17056.008564] ACPI Error: Method parse/execution failed >> [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88026547ea10), AE_TIME >> (20120711/psparse-536) >> [17056.011194] ACPI Error: Method parse/execution failed >> [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME >> (20120711/psparse-536) >> [17056.013793] ACPI Error: Method parse/execution failed >> [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME >> (20120711/psparse-536) >> [17056.016383] ACPI Exception: AE_TIME, Evaluating _BST >> (20120711/battery-464) >> [17056.511373] ACPI: EC: input buffer is not empty, aborting transaction >> [17056.512672] ACPI Exception: AE_TIME, Returned by Handler for >> [EmbeddedControl] (20120711/evregion-501) >> [17056.515256] ACPI Error: Method parse/execution failed >> [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88026547ea10), AE_TIME >> (20120711/psparse-536) >> [17056.517886] ACPI Error: Method parse/execution failed >> [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME >> (20120711/psparse-536) >> [17056.520479] ACPI Error: Method parse/execution failed >> [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME >> (20120711/psparse-536) >> [17056.523070] ACPI Exception: AE_TIME, Evaluating _BST >> (20120711/battery-464) > > I'm seeing this again right now. I'm wondering if it's because I'm > running on battery power at the moment: > > [41694.309264] ACPI Exception: AE_TIME, Returned by Handler for > [EmbeddedControl] (20120913/evregion-501) > [41694.309282] ACPI Error: Method parse/execution failed > [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88045cc64618), AE_TIME > (20120913/psparse-536) > [41694.309300] ACPI Error: Method parse/execution failed [\_SB_.BAT0.UBST] > (Node 88045cc64988), AE_TIME (20120913/psparse-536) > [41694.309310] ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] > (Node 88045cc648c0), AE_TIME (20120913/psparse-536) > [41694.309324] ACPI Exception: AE_TIME, Evaluating _BST (20120913/battery-464) > [41694.809093] ACPI: EC: input buffer is not empty, aborting transaction > > ec_storm_threshold is still set to 8 in /sys/module/acpi/parameters/ so that's > not the issue here. > >> And also loadavg is too high ~ 10 >> While there is no process that load CPU up to 100% or like that. >> I think that this because of processes that is done in kernel space. >> (basically that one who write such errors) >> >> $ uname -a >> Linux macbook-pro-sq 3.6.5macbook-pro-custom-v0.1 #4 SMP Sun Nov 4 >> 12:39:03 UTC 2012 x86_64 GNU/Linux > > Ah, ok, that means it's not something new in 3.7-rc, so maybe it's just never > worked properly for this hardware :) > > So it's not a regression, just an ACPI issue, any ACPI developer have an idea > about this? > > thanks, > > greg k-h -- Azat Khuzhin -- 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: macbook pro 9.2 stat/ata bus error
Anybody?
On Mon, Nov 5, 2012 at 7:28 PM, Azat Khuzhin wrote:
> After installing linux on macbook 9.2 (mid 2012), I have next errors
> in dmesg log:
>
> [ 389.623828] EXT4-fs (sda4): re-mounted. Opts:
> errors=remount-ro,data=ordered,commit=600
> [ 410.038465] NMI watchdog: enabled on all CPUs, permanently consumes
> one hw-PMU counter.
> [ 410.075042] ehci_hcd :00:1a.0: setting latency timer to 64
> [ 410.483526] EXT4-fs (sda4): re-mounted. Opts:
> errors=remount-ro,data=ordered,commit=0
> [ 1401.834509] EXT4-fs (sda4): re-mounted. Opts:
> errors=remount-ro,data=ordered,commit=1800
> [ 1406.467268] NMI watchdog: enabled on all CPUs, permanently consumes
> one hw-PMU counter.
> [ 1406.506769] ehci_hcd :00:1a.0: setting latency timer to 64
> [ 1406.590122] EXT4-fs (sda4): re-mounted. Opts:
> errors=remount-ro,data=ordered,commit=0
> [ 1407.492260] ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x5
> action 0xe frozen
> [ 1407.494441] ata2.00: irq_stat 0x0040, PHY RDY changed
> [ 1407.495238] ata2: SError: { PHYRdyChg CommWake }
> [ 1407.496035] sr 1:0:0:0: CDB:
> [ 1407.497333] Get event status notification: 4a 01 00 00 10 00 00 00 08 00
> [ 1407.498285] ata2.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 0
> pio 16392 in
> [ 1407.498285] res 50/00:03:00:00:00/00:00:00:00:00/a0 Emask
> 0x10 (ATA bus error)
> [ 1407.501987] ata2.00: status: { DRDY }
> [ 1407.502882] ata2: hard resetting link
> [ 1408.230302] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [ 1408.233279] ata2.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES)
> filtered out
> [ 1408.237467] ata2.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES)
> filtered out
> [ 1408.239084] ata2.00: configured for UDMA/100
> [ 1408.262238] ata2: EH complete
> [ 3565.785609] EXT4-fs (sda4): re-mounted. Opts:
> errors=remount-ro,data=ordered,commit=1800
> [ 3576.921499] NMI watchdog: enabled on all CPUs, permanently consumes
> one hw-PMU counter.
> [ 3576.958624] ehci_hcd :00:1a.0: setting latency timer to 64
> [ 3577.114612] EXT4-fs (sda4): re-mounted. Opts:
> errors=remount-ro,data=ordered,commit=0
> [ 3577.923688] ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x5
> action 0xe frozen
> [ 3577.925852] ata2.00: irq_stat 0x0040, PHY RDY changed
> [ 3577.926746] ata2: SError: { PHYRdyChg CommWake }
> [ 3577.927544] sr 1:0:0:0: CDB:
> [ 3577.928345] Get event status notification: 4a 01 00 00 10 00 00 00 08 00
> [ 3577.929642] ata2.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 0
> pio 16392 in
> [ 3577.929642] res 50/00:03:00:00:00/00:00:00:00:00/a0 Emask
> 0x10 (ATA bus error)
> [ 3577.932954] ata2.00: status: { DRDY }
> [ 3577.934264] ata2: hard resetting link
> [ 3578.662228] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [ 3578.665211] ata2.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES)
> filtered out
> [ 3578.669355] ata2.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES)
> filtered out
> [ 3578.670969] ata2.00: configured for UDMA/100
> [ 3578.694145] ata2: EH complete
>
> Is it linux driver, or maybe
>
> $ lspci # sata information only
> 00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family
> 6-port SATA Controller [AHCI mode] (rev 04) (prog-if 01 [AHCI 1.0])
> Subsystem: Intel Corporation Device 7270
> Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 20
> I/O ports at 2098 [size=8]
> I/O ports at 20bc [size=4]
> I/O ports at 2090 [size=8]
> I/O ports at 20b8 [size=4]
> I/O ports at 2060 [size=32]
> Memory at a0816000 (32-bit, non-prefetchable) [size=2K]
> Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
> Capabilities: [70] Power Management version 3
> Capabilities: [a8] SATA HBA v1.0
> Capabilities: [b0] PCI Advanced Features
> Kernel driver in use: ahci
>
> $ uname -a
> Linux macbook-pro 3.6.5macbook-pro-custom-v0.1 #4 SMP Sun Nov 4
> 12:39:03 UTC 2012 x86_64 GNU/Linux
> $ cat /etc/debian_version
> wheezy/sid
>
> In OSX there is no errors with hard drive.
>
> What else can I do investigate this situation next?
>
> --
> Azat Khuzhin
--
Azat Khuzhin
--
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: macbook pro 9.2 stat/ata bus error
Also I want to note that some times notebook was suspended.
But this errors don't appears every time before suspend or just after resume.
On Wed, Nov 7, 2012 at 7:41 AM, Azat Khuzhin wrote:
> Anybody?
>
> On Mon, Nov 5, 2012 at 7:28 PM, Azat Khuzhin wrote:
>> After installing linux on macbook 9.2 (mid 2012), I have next errors
>> in dmesg log:
>>
>> [ 389.623828] EXT4-fs (sda4): re-mounted. Opts:
>> errors=remount-ro,data=ordered,commit=600
>> [ 410.038465] NMI watchdog: enabled on all CPUs, permanently consumes
>> one hw-PMU counter.
>> [ 410.075042] ehci_hcd :00:1a.0: setting latency timer to 64
>> [ 410.483526] EXT4-fs (sda4): re-mounted. Opts:
>> errors=remount-ro,data=ordered,commit=0
>> [ 1401.834509] EXT4-fs (sda4): re-mounted. Opts:
>> errors=remount-ro,data=ordered,commit=1800
>> [ 1406.467268] NMI watchdog: enabled on all CPUs, permanently consumes
>> one hw-PMU counter.
>> [ 1406.506769] ehci_hcd :00:1a.0: setting latency timer to 64
>> [ 1406.590122] EXT4-fs (sda4): re-mounted. Opts:
>> errors=remount-ro,data=ordered,commit=0
>> [ 1407.492260] ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x5
>> action 0xe frozen
>> [ 1407.494441] ata2.00: irq_stat 0x0040, PHY RDY changed
>> [ 1407.495238] ata2: SError: { PHYRdyChg CommWake }
>> [ 1407.496035] sr 1:0:0:0: CDB:
>> [ 1407.497333] Get event status notification: 4a 01 00 00 10 00 00 00 08 00
>> [ 1407.498285] ata2.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 0
>> pio 16392 in
>> [ 1407.498285] res 50/00:03:00:00:00/00:00:00:00:00/a0 Emask
>> 0x10 (ATA bus error)
>> [ 1407.501987] ata2.00: status: { DRDY }
>> [ 1407.502882] ata2: hard resetting link
>> [ 1408.230302] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>> [ 1408.233279] ata2.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES)
>> filtered out
>> [ 1408.237467] ata2.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES)
>> filtered out
>> [ 1408.239084] ata2.00: configured for UDMA/100
>> [ 1408.262238] ata2: EH complete
>> [ 3565.785609] EXT4-fs (sda4): re-mounted. Opts:
>> errors=remount-ro,data=ordered,commit=1800
>> [ 3576.921499] NMI watchdog: enabled on all CPUs, permanently consumes
>> one hw-PMU counter.
>> [ 3576.958624] ehci_hcd :00:1a.0: setting latency timer to 64
>> [ 3577.114612] EXT4-fs (sda4): re-mounted. Opts:
>> errors=remount-ro,data=ordered,commit=0
>> [ 3577.923688] ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x5
>> action 0xe frozen
>> [ 3577.925852] ata2.00: irq_stat 0x0040, PHY RDY changed
>> [ 3577.926746] ata2: SError: { PHYRdyChg CommWake }
>> [ 3577.927544] sr 1:0:0:0: CDB:
>> [ 3577.928345] Get event status notification: 4a 01 00 00 10 00 00 00 08 00
>> [ 3577.929642] ata2.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 0
>> pio 16392 in
>> [ 3577.929642] res 50/00:03:00:00:00/00:00:00:00:00/a0 Emask
>> 0x10 (ATA bus error)
>> [ 3577.932954] ata2.00: status: { DRDY }
>> [ 3577.934264] ata2: hard resetting link
>> [ 3578.662228] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>> [ 3578.665211] ata2.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES)
>> filtered out
>> [ 3578.669355] ata2.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES)
>> filtered out
>> [ 3578.670969] ata2.00: configured for UDMA/100
>> [ 3578.694145] ata2: EH complete
>>
>> Is it linux driver, or maybe
>>
>> $ lspci # sata information only
>> 00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family
>> 6-port SATA Controller [AHCI mode] (rev 04) (prog-if 01 [AHCI 1.0])
>> Subsystem: Intel Corporation Device 7270
>> Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 20
>> I/O ports at 2098 [size=8]
>> I/O ports at 20bc [size=4]
>> I/O ports at 2090 [size=8]
>> I/O ports at 20b8 [size=4]
>> I/O ports at 2060 [size=32]
>> Memory at a0816000 (32-bit, non-prefetchable) [size=2K]
>> Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
>> Capabilities: [70] Power Management version 3
>> Capabilities: [a8] SATA HBA v1.0
>> Capabilities: [b0] PCI Advanced Features
>> Kernel driver in use: ahci
>>
>> $ uname -a
>> Linux macbook-pro 3.6.5macbook-pro-custom-v0.1 #4 SMP Sun Nov 4
>> 12:39:03 UTC 2012 x86_64 GNU/Linux
>> $ cat /etc/debian_version
>> wheezy/sid
>>
>> In OSX there is no errors with hard drive.
>>
>> What else can I do investigate this situation next?
>>
>> --
>> Azat Khuzhin
>
>
>
> --
> Azat Khuzhin
--
Azat Khuzhin
--
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: ACPI errors with 3.7-rc3
Here is mine - https://gist.github.com/4037687 To Greg: acpidump 20100513-3.1 And I don't have pmtools installed On Thu, Nov 8, 2012 at 8:47 AM, Greg KH wrote: > On Wed, Nov 07, 2012 at 10:49:40PM +0100, Rafael J. Wysocki wrote: >> On Tuesday, November 06, 2012 01:48:26 PM Greg KH wrote: >> > On Tue, Nov 06, 2012 at 04:42:24PM +0400, Azat Khuzhin wrote: >> > > I'v also have such errors on my macbook pro. >> > > >> > > $ dmesg | tail >> > > [17056.008564] ACPI Error: Method parse/execution failed >> > > [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88026547ea10), AE_TIME >> > > (20120711/psparse-536) >> > > [17056.011194] ACPI Error: Method parse/execution failed >> > > [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME >> > > (20120711/psparse-536) >> > > [17056.013793] ACPI Error: Method parse/execution failed >> > > [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME >> > > (20120711/psparse-536) >> > > [17056.016383] ACPI Exception: AE_TIME, Evaluating _BST >> > > (20120711/battery-464) >> > > [17056.511373] ACPI: EC: input buffer is not empty, aborting transaction >> > > [17056.512672] ACPI Exception: AE_TIME, Returned by Handler for >> > > [EmbeddedControl] (20120711/evregion-501) >> > > [17056.515256] ACPI Error: Method parse/execution failed >> > > [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88026547ea10), AE_TIME >> > > (20120711/psparse-536) >> > > [17056.517886] ACPI Error: Method parse/execution failed >> > > [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME >> > > (20120711/psparse-536) >> > > [17056.520479] ACPI Error: Method parse/execution failed >> > > [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME >> > > (20120711/psparse-536) >> > > [17056.523070] ACPI Exception: AE_TIME, Evaluating _BST >> > > (20120711/battery-464) >> > >> > I'm seeing this again right now. I'm wondering if it's because I'm >> > running on battery power at the moment: >> > >> > [41694.309264] ACPI Exception: AE_TIME, Returned by Handler for >> > [EmbeddedControl] (20120913/evregion-501) >> > [41694.309282] ACPI Error: Method parse/execution failed >> > [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88045cc64618), AE_TIME >> > (20120913/psparse-536) >> > [41694.309300] ACPI Error: Method parse/execution failed [\_SB_.BAT0.UBST] >> > (Node 88045cc64988), AE_TIME (20120913/psparse-536) >> > [41694.309310] ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] >> > (Node 88045cc648c0), AE_TIME (20120913/psparse-536) >> > [41694.309324] ACPI Exception: AE_TIME, Evaluating _BST >> > (20120913/battery-464) >> > [41694.809093] ACPI: EC: input buffer is not empty, aborting transaction >> > >> > ec_storm_threshold is still set to 8 in /sys/module/acpi/parameters/ so >> > that's >> > not the issue here. >> > >> > > And also loadavg is too high ~ 10 >> > > While there is no process that load CPU up to 100% or like that. >> > > I think that this because of processes that is done in kernel space. >> > > (basically that one who write such errors) >> > > >> > > $ uname -a >> > > Linux macbook-pro-sq 3.6.5macbook-pro-custom-v0.1 #4 SMP Sun Nov 4 >> > > 12:39:03 UTC 2012 x86_64 GNU/Linux >> > >> > Ah, ok, that means it's not something new in 3.7-rc, so maybe it's just >> > never >> > worked properly for this hardware :) >> > >> > So it's not a regression, just an ACPI issue, any ACPI developer have an >> > idea >> > about this? >> >> Can you please send the output of acpidump from the affected machine(s)? > > # ./acpidump > ACPI tables were not found. If you know location of RSD PTR table (from > dmesg, etc), supply it with either --addr or -a option > > What am I doing wrong here? > > Is there a newer version of pmtools than the one labled pmtools-20071116 > that I should be using? A link to download it would be appreciated. > > thanks, > > greg k-h -- Azat Khuzhin -- 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: macbook pro 9.2 stat/ata bus error
Yeah, I'm guessed about this.
Thanks for reply.
On Fri, Nov 9, 2012 at 7:48 AM, Robert Hancock wrote:
> On 11/06/2012 09:41 PM, Azat Khuzhin wrote:
>>
>> Anybody?
>>
>> On Mon, Nov 5, 2012 at 7:28 PM, Azat Khuzhin
>> wrote:
>>>
>>> After installing linux on macbook 9.2 (mid 2012), I have next errors
>>> in dmesg log:
>>>
>>> [ 389.623828] EXT4-fs (sda4): re-mounted. Opts:
>>> errors=remount-ro,data=ordered,commit=600
>>> [ 410.038465] NMI watchdog: enabled on all CPUs, permanently consumes
>>> one hw-PMU counter.
>>> [ 410.075042] ehci_hcd :00:1a.0: setting latency timer to 64
>>> [ 410.483526] EXT4-fs (sda4): re-mounted. Opts:
>>> errors=remount-ro,data=ordered,commit=0
>>> [ 1401.834509] EXT4-fs (sda4): re-mounted. Opts:
>>> errors=remount-ro,data=ordered,commit=1800
>>> [ 1406.467268] NMI watchdog: enabled on all CPUs, permanently consumes
>>> one hw-PMU counter.
>>> [ 1406.506769] ehci_hcd :00:1a.0: setting latency timer to 64
>>> [ 1406.590122] EXT4-fs (sda4): re-mounted. Opts:
>>> errors=remount-ro,data=ordered,commit=0
>>> [ 1407.492260] ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x5
>>> action 0xe frozen
>>> [ 1407.494441] ata2.00: irq_stat 0x0040, PHY RDY changed
>>> [ 1407.495238] ata2: SError: { PHYRdyChg CommWake }
>>> [ 1407.496035] sr 1:0:0:0: CDB:
>>> [ 1407.497333] Get event status notification: 4a 01 00 00 10 00 00 00 08
>>> 00
>>> [ 1407.498285] ata2.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 0
>>> pio 16392 in
>>> [ 1407.498285] res 50/00:03:00:00:00/00:00:00:00:00/a0 Emask
>>> 0x10 (ATA bus error)
>>> [ 1407.501987] ata2.00: status: { DRDY }
>>> [ 1407.502882] ata2: hard resetting link
>>> [ 1408.230302] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>> [ 1408.233279] ata2.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES)
>>> filtered out
>>> [ 1408.237467] ata2.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES)
>>> filtered out
>>> [ 1408.239084] ata2.00: configured for UDMA/100
>>> [ 1408.262238] ata2: EH complete
>
>
> Is this after a resume? It could be that for some reason the SATA link is a
> little bit unstable right after the machine powers up again. There may not
> be much the kernel can do about this..
>
>
>>> [ 3565.785609] EXT4-fs (sda4): re-mounted. Opts:
>>> errors=remount-ro,data=ordered,commit=1800
>>> [ 3576.921499] NMI watchdog: enabled on all CPUs, permanently consumes
>>> one hw-PMU counter.
>>> [ 3576.958624] ehci_hcd :00:1a.0: setting latency timer to 64
>>> [ 3577.114612] EXT4-fs (sda4): re-mounted. Opts:
>>> errors=remount-ro,data=ordered,commit=0
>>> [ 3577.923688] ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x5
>>> action 0xe frozen
>>> [ 3577.925852] ata2.00: irq_stat 0x0040, PHY RDY changed
>>> [ 3577.926746] ata2: SError: { PHYRdyChg CommWake }
>>> [ 3577.927544] sr 1:0:0:0: CDB:
>>> [ 3577.928345] Get event status notification: 4a 01 00 00 10 00 00 00 08
>>> 00
>>> [ 3577.929642] ata2.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 0
>>> pio 16392 in
>>> [ 3577.929642] res 50/00:03:00:00:00/00:00:00:00:00/a0 Emask
>>> 0x10 (ATA bus error)
>>> [ 3577.932954] ata2.00: status: { DRDY }
>>> [ 3577.934264] ata2: hard resetting link
>>> [ 3578.662228] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>> [ 3578.665211] ata2.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES)
>>> filtered out
>>> [ 3578.669355] ata2.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES)
>>> filtered out
>>> [ 3578.670969] ata2.00: configured for UDMA/100
>>> [ 3578.694145] ata2: EH complete
>>>
>>> Is it linux driver, or maybe
>>>
>>> $ lspci # sata information only
>>> 00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family
>>> 6-port SATA Controller [AHCI mode] (rev 04) (prog-if 01 [AHCI 1.0])
>>> Subsystem: Intel Corporation Device 7270
>>> Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 20
>>> I/O ports at 2098 [size=8]
>>> I/O ports at 20bc [size=4]
>>> I/O ports at 2090 [size=8]
>>> I/O ports at 20b8 [size=4]
>>> I/O ports at 2060 [size=32]
>>> Memory at a0816000 (32-bit, non-prefetchable) [size=2K]
>>> Capabilities: [80] MSI: Enable+ Count=1/1 Maska
Re: ACPI errors with 3.7-rc3
Robert, You say that FACS table contains the address of the global lock. But in my case https://gist.github.com/4037687 it seems to be empty, so this means that my laptop don't have global lock? On Fri, Nov 9, 2012 at 8:45 PM, Moore, Robert wrote: >> And per my check, most of ACPI FW don't implement this lock, say after >> driver probe, the ec->global_lock will be 0 > > Take a look at the FACS table, it contains the address of the global lock. > > I believe that the ACPI specification requires that the global lock be > present. > > > >> -Original Message- >> From: Tang, Feng >> Sent: Friday, November 09, 2012 8:36 AM >> To: Moore, Robert >> Cc: Rafael J. Wysocki; Greg KH; Azat Khuzhin; linux-a...@vger.kernel.org; >> Linux Kernel Mailing List; Zheng, Lv; Len Brown >> Subject: Re: ACPI errors with 3.7-rc3 >> >> On Fri, Nov 09, 2012 at 10:30:43PM +0800, Moore, Robert wrote: >> > The ACPI Global Lock is in fact intended to provide exclusion between >> the BIOS and the OS. >> > Bob >> >> Thanks for the info. >> >> And per my check, most of ACPI FW don't implement this lock, say after >> driver probe, the ec->global_lock will be 0. >> >> - Feng >> >> > >> > >> > > -Original Message- >> > > From: Tang, Feng >> > > Sent: Friday, November 09, 2012 1:29 AM >> > > To: Rafael J. Wysocki >> > > Cc: Greg KH; Azat Khuzhin; linux-a...@vger.kernel.org; Linux Kernel >> > > Mailing List; Zheng, Lv; Len Brown; Moore, Robert >> > > Subject: Re: ACPI errors with 3.7-rc3 >> > > >> > > On Thu, Nov 08, 2012 at 05:49:40AM +0800, Rafael J. Wysocki wrote: >> > > > On Tuesday, November 06, 2012 01:48:26 PM Greg KH wrote: >> > > > > On Tue, Nov 06, 2012 at 04:42:24PM +0400, Azat Khuzhin wrote: >> > > > > > I'v also have such errors on my macbook pro. >> > > > > > >> > > > > > $ dmesg | tail >> > > > > > [17056.008564] ACPI Error: Method parse/execution failed >> > > > > > [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88026547ea10), >> > > > > > AE_TIME >> > > > > > (20120711/psparse-536) >> > > > > > [17056.011194] ACPI Error: Method parse/execution failed >> > > > > > [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME >> > > > > > (20120711/psparse-536) >> > > > > > [17056.013793] ACPI Error: Method parse/execution failed >> > > > > > [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME >> > > > > > (20120711/psparse-536) >> > > > > > [17056.016383] ACPI Exception: AE_TIME, Evaluating _BST >> > > > > > (20120711/battery-464) [17056.511373] ACPI: EC: input buffer >> > > > > > is not empty, aborting transaction [17056.512672] ACPI >> Exception: >> > > > > > AE_TIME, Returned by Handler for [EmbeddedControl] >> > > > > > (20120711/evregion-501) [17056.515256] ACPI Error: Method >> > > > > > parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node >> > > > > > 88026547ea10), AE_TIME >> > > > > > (20120711/psparse-536) >> > > > > > [17056.517886] ACPI Error: Method parse/execution failed >> > > > > > [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME >> > > > > > (20120711/psparse-536) >> > > > > > [17056.520479] ACPI Error: Method parse/execution failed >> > > > > > [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME >> > > > > > (20120711/psparse-536) >> > > > > > [17056.523070] ACPI Exception: AE_TIME, Evaluating _BST >> > > > > > (20120711/battery-464) >> > > > > >> > > > > I'm seeing this again right now. I'm wondering if it's because >> > > > > I'm running on battery power at the moment: >> > > > > >> > > > > [41694.309264] ACPI Exception: AE_TIME, Returned by Handler for >> > > > > [EmbeddedControl] (20120913/evregion-501) [41694.309282] ACPI >> Error: >> > > > > Method parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] >> > > > > (Node 88045cc64618), AE_TIME (20120913/psparse-536) >> > > > > [41694.309300] ACPI Error: Method parse/execution failed >> > &
Re: macbook pro 9.2 stat/ata bus error
Also I have notice next thing:
At 04:21 I close lid, and laptop automatically suspend, with the
following messages in the log:
Nov 11 04:21:49 macbook-pro-sq kernel: [19489.114021] ata2.00:
exception Emask 0x10 SAct 0x0 SErr 0x5 action 0xe frozen
Nov 11 04:21:49 macbook-pro-sq kernel: [19489.116459] ata2.00:
irq_stat 0x0040, PHY RDY changed
Nov 11 04:21:49 macbook-pro-sq kernel: [19489.117665] ata2: SError: {
PHYRdyChg CommWake }
Nov 11 04:21:49 macbook-pro-sq kernel: [19489.118854] sr 1:0:0:0: CDB:
Nov 11 04:21:49 macbook-pro-sq kernel: [19489.120061] Get event status
notification: 4a 01 00 00 10 00 00 00 08 00
Nov 11 04:21:49 macbook-pro-sq kernel: [19489.121275] ata2.00: cmd
a0/00:00:00:08:00/00:00:00:00:00/a0 tag 0 pio 16392 in
Nov 11 04:21:49 macbook-pro-sq kernel: [19489.121275] res
50/00:03:00:00:00/00:00:00:00:00/a0 Emask 0x10 (ATA bus error)
Nov 11 04:21:49 macbook-pro-sq kernel: [19489.126075] ata2.00: status: { DRDY }
Nov 11 04:21:49 macbook-pro-sq kernel: [19489.127304] ata2: hard resetting link
But when I try to resume, it not turn on normally, the monitor don't bright.
Laptop came out of suspend, I detected this by indicator at the front.
I think that because of it can't read from HDD.
Am I right? What can I do next to investigate further?
On Sat, Nov 10, 2012 at 5:22 PM, Azat Khuzhin wrote:
> Yeah, I'm guessed about this.
> Thanks for reply.
>
> On Fri, Nov 9, 2012 at 7:48 AM, Robert Hancock wrote:
>> On 11/06/2012 09:41 PM, Azat Khuzhin wrote:
>>>
>>> Anybody?
>>>
>>> On Mon, Nov 5, 2012 at 7:28 PM, Azat Khuzhin
>>> wrote:
>>>>
>>>> After installing linux on macbook 9.2 (mid 2012), I have next errors
>>>> in dmesg log:
>>>>
>>>> [ 389.623828] EXT4-fs (sda4): re-mounted. Opts:
>>>> errors=remount-ro,data=ordered,commit=600
>>>> [ 410.038465] NMI watchdog: enabled on all CPUs, permanently consumes
>>>> one hw-PMU counter.
>>>> [ 410.075042] ehci_hcd :00:1a.0: setting latency timer to 64
>>>> [ 410.483526] EXT4-fs (sda4): re-mounted. Opts:
>>>> errors=remount-ro,data=ordered,commit=0
>>>> [ 1401.834509] EXT4-fs (sda4): re-mounted. Opts:
>>>> errors=remount-ro,data=ordered,commit=1800
>>>> [ 1406.467268] NMI watchdog: enabled on all CPUs, permanently consumes
>>>> one hw-PMU counter.
>>>> [ 1406.506769] ehci_hcd :00:1a.0: setting latency timer to 64
>>>> [ 1406.590122] EXT4-fs (sda4): re-mounted. Opts:
>>>> errors=remount-ro,data=ordered,commit=0
>>>> [ 1407.492260] ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x5
>>>> action 0xe frozen
>>>> [ 1407.494441] ata2.00: irq_stat 0x0040, PHY RDY changed
>>>> [ 1407.495238] ata2: SError: { PHYRdyChg CommWake }
>>>> [ 1407.496035] sr 1:0:0:0: CDB:
>>>> [ 1407.497333] Get event status notification: 4a 01 00 00 10 00 00 00 08
>>>> 00
>>>> [ 1407.498285] ata2.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 0
>>>> pio 16392 in
>>>> [ 1407.498285] res 50/00:03:00:00:00/00:00:00:00:00/a0 Emask
>>>> 0x10 (ATA bus error)
>>>> [ 1407.501987] ata2.00: status: { DRDY }
>>>> [ 1407.502882] ata2: hard resetting link
>>>> [ 1408.230302] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>>> [ 1408.233279] ata2.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES)
>>>> filtered out
>>>> [ 1408.237467] ata2.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES)
>>>> filtered out
>>>> [ 1408.239084] ata2.00: configured for UDMA/100
>>>> [ 1408.262238] ata2: EH complete
>>
>>
>> Is this after a resume? It could be that for some reason the SATA link is a
>> little bit unstable right after the machine powers up again. There may not
>> be much the kernel can do about this..
>>
>>
>>>> [ 3565.785609] EXT4-fs (sda4): re-mounted. Opts:
>>>> errors=remount-ro,data=ordered,commit=1800
>>>> [ 3576.921499] NMI watchdog: enabled on all CPUs, permanently consumes
>>>> one hw-PMU counter.
>>>> [ 3576.958624] ehci_hcd :00:1a.0: setting latency timer to 64
>>>> [ 3577.114612] EXT4-fs (sda4): re-mounted. Opts:
>>>> errors=remount-ro,data=ordered,commit=0
>>>> [ 3577.923688] ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x5
>>>> action 0xe frozen
>>>> [ 3577.925852] ata2.00: irq_stat 0x0040, PHY RDY changed
>>>> [ 3577.926746] ata2: SError: { PHYRdyChg CommWake }
>>>> [ 3577.927544] sr 1:0:0:0: CDB:
>>>> [ 3577
[PATCH] btrfs: use list_for_each_entry_safe() when delete items
Replace list_for_each_entry() by list_for_each_entry_safe() in next
functions:
- lock_stripe_add()
- __btrfs_close_devices()
Signed-off-by: Azat Khuzhin
---
fs/btrfs/raid56.c |4 ++--
fs/btrfs/volumes.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
index 0525e13..37e6dc9 100644
--- a/fs/btrfs/raid56.c
+++ b/fs/btrfs/raid56.c
@@ -636,7 +636,7 @@ static noinline int lock_stripe_add(struct btrfs_raid_bio
*rbio)
{
int bucket = rbio_bucket(rbio);
struct btrfs_stripe_hash *h = rbio->fs_info->stripe_hash_table->table +
bucket;
- struct btrfs_raid_bio *cur;
+ struct btrfs_raid_bio *cur, *next;
struct btrfs_raid_bio *pending;
unsigned long flags;
DEFINE_WAIT(wait);
@@ -646,7 +646,7 @@ static noinline int lock_stripe_add(struct btrfs_raid_bio
*rbio)
int walk = 0;
spin_lock_irqsave(&h->lock, flags);
- list_for_each_entry(cur, &h->hash_list, hash_list) {
+ list_for_each_entry_safe(cur, next, &h->hash_list, hash_list) {
walk++;
if (cur->raid_map[0] == rbio->raid_map[0]) {
spin_lock(&cur->bio_list_lock);
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 78b8717..1d1b595 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -616,13 +616,13 @@ static void free_device(struct rcu_head *head)
static int __btrfs_close_devices(struct btrfs_fs_devices *fs_devices)
{
- struct btrfs_device *device;
+ struct btrfs_device *device, *next;
if (--fs_devices->opened > 0)
return 0;
mutex_lock(&fs_devices->device_list_mutex);
- list_for_each_entry(device, &fs_devices->devices, dev_list) {
+ list_for_each_entry_safe(device, next, &fs_devices->devices, dev_list) {
struct btrfs_device *new_device;
struct rcu_string *name;
--
1.7.10.4
--
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/
[PATCH] btrfs: use list_for_each_entry_safe() when delete items
Replace list_for_each_entry() by list_for_each_entry_safe() in
__btrfs_close_devices()
There is another place that delete items lock_stripe_add(), but there we
don't need safe version, because after deleting we exit from loop.
Signed-off-by: Azat Khuzhin
---
fs/btrfs/volumes.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 78b8717..1d1b595 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -616,13 +616,13 @@ static void free_device(struct rcu_head *head)
static int __btrfs_close_devices(struct btrfs_fs_devices *fs_devices)
{
- struct btrfs_device *device;
+ struct btrfs_device *device, *next;
if (--fs_devices->opened > 0)
return 0;
mutex_lock(&fs_devices->device_list_mutex);
- list_for_each_entry(device, &fs_devices->devices, dev_list) {
+ list_for_each_entry_safe(device, next, &fs_devices->devices, dev_list) {
struct btrfs_device *new_device;
struct rcu_string *name;
--
1.7.10.4
--
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] btrfs: use list_for_each_entry_safe() when delete items
On Sat, Jul 27, 2013 at 2:12 PM, Azat Khuzhin wrote:
> Replace list_for_each_entry() by list_for_each_entry_safe() in
> __btrfs_close_devices()
>
> There is another place that delete items lock_stripe_add(), but there we
> don't need safe version, because after deleting we exit from loop.
>
> Signed-off-by: Azat Khuzhin
> ---
> fs/btrfs/volumes.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index 78b8717..1d1b595 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -616,13 +616,13 @@ static void free_device(struct rcu_head *head)
>
> static int __btrfs_close_devices(struct btrfs_fs_devices *fs_devices)
> {
> - struct btrfs_device *device;
> + struct btrfs_device *device, *next;
>
> if (--fs_devices->opened > 0)
> return 0;
>
> mutex_lock(&fs_devices->device_list_mutex);
> - list_for_each_entry(device, &fs_devices->devices, dev_list) {
> + list_for_each_entry_safe(device, next, &fs_devices->devices,
> dev_list) {
> struct btrfs_device *new_device;
> struct rcu_string *name;
There is "kfree(device);" at the end of loop, maybe there must "goto
again;" after it?
(instead of this patch)
>
> --
> 1.7.10.4
>
--
Respectfully
Azat Khuzhin
--
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/
[PATCH] mm: for shm_open()/mmap() with OVERCOMMIT_NEVER, return -1 if no memory avail
Otherwize if there is no left space on shmem device, there will be
"Bus error" when application will try to write to address space that was
returned by mmap(2)
This patch also preserve old behaviour if MAP_NORESERVE/VM_NORESERVE
isset.
So, with this patch, you will get next:
a)
$ echo 2 >| /proc/sys/vm/overcommit_memory
mmap() = MAP_FAILED;
b)
mmap(0, length, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_NORESERVE) =
!MAP_FAILED;
write()
killed by SIGBUS
c)
$ echo 0 >| /proc/sys/vm/overcommit_memory
mmap() = !MAP_FAILED;
write()
killed by SIGBUS
Signed-off-by: Azat Khuzhin
---
mm/shmem.c | 16
1 file changed, 16 insertions(+)
diff --git a/mm/shmem.c b/mm/shmem.c
index a87990c..965f4ba 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -32,6 +32,8 @@
#include
#include
#include
+#include
+#include
static struct vfsmount *shm_mnt;
@@ -1356,6 +1358,20 @@ out_nomem:
static int shmem_mmap(struct file *file, struct vm_area_struct *vma)
{
+ if (!(vma->vm_flags & VM_NORESERVE) &&
+ sysctl_overcommit_memory == OVERCOMMIT_NEVER) {
+ struct inode *inode = file_inode(file);
+ struct kstatfs sbuf;
+ u64 size;
+
+ inode->i_sb->s_op->statfs(file->f_dentry, &sbuf);
+ size = sbuf.f_bfree * sbuf.f_bsize;
+
+ if (size < inode->i_size) {
+ return -ENOMEM;
+ }
+ }
+
file_accessed(file);
vma->vm_ops = &shmem_vm_ops;
return 0;
--
1.7.10.4
--
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] mm: for shm_open()/mmap() with OVERCOMMIT_NEVER, return -1 if no memory avail
On Wed, Jul 31, 2013 at 10:32 AM, Hugh Dickins wrote:
> On Tue, 30 Jul 2013, Azat Khuzhin wrote:
>
>> Otherwize if there is no left space on shmem device, there will be
>> "Bus error" when application will try to write to address space that was
>> returned by mmap(2)
>>
>> This patch also preserve old behaviour if MAP_NORESERVE/VM_NORESERVE
>> isset.
>>
>> So, with this patch, you will get next:
>>
>> a)
>> $ echo 2 >| /proc/sys/vm/overcommit_memory
>>
>> mmap() = MAP_FAILED;
>>
>>
>> b)
>>
>> mmap(0, length, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_NORESERVE) =
>> !MAP_FAILED;
>> write()
>> killed by SIGBUS
>>
>>
>> c)
>> $ echo 0 >| /proc/sys/vm/overcommit_memory
>>
>> mmap() = !MAP_FAILED;
>> write()
>> killed by SIGBUS
>>
>>
>> Signed-off-by: Azat Khuzhin
>
> Thanks for making the patch, but I'm afraid there are a number of
> things wrong with it; and even if it were perfect, I would still be
> reluctant to change the semantics of shmem_mmap() after all this time.
I was also think about this, but hence it only change behavior with
OVERCOMMIT_NEVER, I post this patch.
>
> Some comments on your implementation below; but if getting SIGBUS from
> a write to an mmapping, once the underlying filesystem (shmem/tmpfs or
> any other) fills up, if that SIGBUS is troublesome for you, then please
> try using fallocate() to allocate the space before accessing the mmapping.
Oh.. forgot about fallocate().
Thanks for you comments, I will keep in mind!
>
>> ---
>> mm/shmem.c | 16
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/mm/shmem.c b/mm/shmem.c
>> index a87990c..965f4ba 100644
>> --- a/mm/shmem.c
>> +++ b/mm/shmem.c
>> @@ -32,6 +32,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>
> I'm surprised you need either of those: vfs.h should have already
> included statfs.h, and I don't see what path.h would be for.
>
>>
>> static struct vfsmount *shm_mnt;
>>
>> @@ -1356,6 +1358,20 @@ out_nomem:
>>
>> static int shmem_mmap(struct file *file, struct vm_area_struct *vma)
>> {
>> + if (!(vma->vm_flags & VM_NORESERVE) &&
>> + sysctl_overcommit_memory == OVERCOMMIT_NEVER) {
>
> So, this would be a new and different usage of sysctl_overcommit_memory:
> usually it applies to vm_committed_as accounting, but you're extending
> it to affect tmpfs filesystem size accounting. Hmm.
>
>> + struct inode *inode = file_inode(file);
>> + struct kstatfs sbuf;
>> + u64 size;
>> +
>> + inode->i_sb->s_op->statfs(file->f_dentry, &sbuf);
>
> You don't really need to go through ->statfs(), since that will arrive
> at shmem_statfs(). Where you can see there will be a problem in the
> case of an unlimited (max_blocks=0) mount - you will fail mmap() of
> every file of non-0 size - and mmaps of 0-size files aren't much use!
> But moving on from that case...
Nice catch, thanks!
>
>> + size = sbuf.f_bfree * sbuf.f_bsize;
>> +
>> + if (size < inode->i_size) {
>> + return -ENOMEM;
>
> So, if your filesystem is full, mmap() of any (i_size>0) file in it will
> fail? I don't think that's what you want at all. You seem to be assuming
> that no pages of the file you're mmap()ing have been allocated yet: that
> may be the case, but it's very often not so.
>
>> + }
>
> And if we pass that test, there's stll no assurance that you won't get
> SIGBUS from accessing the mmapping: nothing has actually been reserved
> here, and other activity on the system can gobble up all the remaining
> space in the filesystem, or take vm_committed_as to its maximum.
Completely slipped my mind.
>
>> + }
>> +
>> file_accessed(file);
>> vma->vm_ops = &shmem_vm_ops;
>> return 0;
>> --
>> 1.7.10.4
>
> Please "man 2 fallocate" and use that instead.
>
> Hugh
--
Respectfully
Azat Khuzhin
--
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: [git pull] drm merge for 3.9-rc1
On Wed, Feb 27, 2013 at 5:39 AM, Linus Torvalds
wrote:
> On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie wrote:
>>
>> Highlights:
>>
>> i915: all over the map, haswell power well enhancements, valleyview macro
>> horrors cleaned up, killing lots of legacy GTT
>> code,
>
> Lowlight:
>
> There's something wrong with i915 DP detection or whatever. I get
> stuff like this:
>
> [5.710827] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [5.720810] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [5.730794] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [5.740782] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [5.750775] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [5.750778] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status
> 0xa145003f
> .
> [8.149931] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status
> 0xa145003f
I have the same messages after upgrading up to
b0af9cd9aab60ceb17d3ebabb9fdf4ff0a99cf50
But in my case when I reboot computer the second monitor, that plugged
via HDMI, didn't works, end when I run `xrandr`, I have next messages
in kern.log
Mar 3 18:09:15 home-spb kernel: [12321.758273] [drm:intel_dp_aux_ch]
*ERROR* dp_aux_ch not done status 0xa143003f
Mar 3 18:09:15 home-spb kernel: [12321.771715]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
Mar 3 18:09:15 home-spb kernel: [12321.782712]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
Mar 3 18:09:15 home-spb kernel: [12321.793715]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
Mar 3 18:09:15 home-spb kernel: [12321.804719]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
Mar 3 18:09:15 home-spb kernel: [12321.815725]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
Mar 3 18:09:15 home-spb kernel: [12321.817293] [drm:intel_dp_aux_ch]
*ERROR* dp_aux_ch not done status 0xa143003f
# lspci | fgrep -i graph
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
Core Processor Family Integrated Graphics Controller (rev 09)
I tested some commits, and here the results:
- Breaked at v3.8-10206-gb0af9cd
- Works normal v3.8-rc3-139-g34f2be4
- Works normal v3.8-rc3-188-g10aa17c
- Works normal 6dc1c49
I've tested 0001-drm-i915-only-use-irq-for-dp-on-post-ilk.patch and it
works for me.
Thank, Dave.
>
> and after that the screen ends up black.
>
> It's happened twice now, but is not 100% repeatable. It looks like the
> message itself is new, but the black screen is also new and does seem
> to happen when I get the message, so...
>
> The second time I touched the power button, and the machine came back.
> Apparently the suspend/resume cycle made it all magically work: the
> suspend caused the same errors, but then the resume made it all good
> again.
>
> Some kind of missed initialization at bootup? It's not reliable enough
> to bisect, but I obviously suspect commit 9ee32fea5fe8 ("drm/i915:
> irq-drive the dp aux communication") since that is where the message
> was added..
>
> Btw, looking at that commit, what do you think the semantics of the
> timeout in something like
>
> done = wait_event_timeout(dev_priv->gmbus_wait_queue, C, 10);
>
> would be? What's that magic "10"? It's some totally random number.
>
> Guys, it should be something meaningful. If you meant a tenth of a
> second, use HZ/10 or something. Because just the plain "10" is crazy.
> I happen to have CONFIG_HZ_1000=y, and you're apparently waiting for a
> hundreth of a second. Was that what you intended? Because if it was,
> it is still crap, since CONFIG_HZ might be 100, and then you're
> waiting for ten times longer.
>
> IOW, passing in a random number like that is crazy. It cannot possibly
> be right.
>
> I have no idea whether the timeout has anything to do with anything,
> but it reinforces my suspicion that there is something wrong with that
> commit.
>
> Linus
> --
> 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/
--
Respectfully
Azat Khuzhin
Primary email a3at.m...@gmail.com
--
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/
high load average in linux-3.6
Hi all. After updating to linux-v3.6-rc1-315-g3c31a6e I noticed that load avg is too high for "current" CPU usage & IO activity Just after starting, I see next things: 1) I'v kill all processes that I "can" iostat_min_tasks - http://pastebin.com/T59xKEy4 ps_min_tasks - http://pastebin.com/b7zVy6up w_min_tasks - http://pastebin.com/UFFsncSn 2) After I started some processes/services (kde,nginx,mysql ...) iostat_with_graph - http://pastebin.com/bejGneGv ps_with_graph - http://pastebin.com/Nt9g0ynW w_with_graph - http://pastebin.com/pYuUbyVY ( graph - with DE ) When I 3.3.0 I did not notice such situation. I'v trying to set kernel cmd line to "i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 drm.vblankoffdelay=1" like here https://bugs.archlinux.org/task/29850 But this doesn't helps. -- Azat Khuzhin -- 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: [GIT PULL] sound updates for 4.21
> This is unfortunately a known issue with this driver, Takashi and I had > a couple of email threads on this. Even without errors removing the > module doesn't seem to release all resources. I don't like this at all, > and for the Sound Open Firmware (SOF) driver I mandated module > load-unload as a functional requirement along with zero warnings w/ > Sparse, Coccinelle and friends, but on this legacy code I am afraid > there is no simple fix - at least not in a merge window or a single > kernel cycle. And the fact that kernel crashes after? Just want extra confirmation Thanks, Azat.
Re: [GIT PULL] sound updates for 4.21
> +/* CFL and later models, preferring ASoC when DSP is available */
> +#define IS_CFL_PLUS(pci)\
> + ((pci)->vendor == 0x8086 && \
> +((pci)->device == 0xa348 || \
> + (pci)->device == 0x9dc8 || \
> + (pci)->device == 0x34c8))
> +
> static char *driver_short_names[] = {
> [AZX_DRIVER_ICH] = "HDA Intel",
> [AZX_DRIVER_PCH] = "HDA Intel PCH",
> @@ -2056,7 +2063,7 @@ static int azx_probe(struct pci_dev *pci,
> if (pci_id->driver_data & AZX_DCAPS_INTEL_SHARED) {
> switch (skl_pci_binding) {
> case SND_SKL_PCI_BIND_AUTO:
> - if (pci->class != 0x040300) {
> + if (pci->class != 0x040300 && IS_CFL_PLUS(pci)) {
> dev_info(&pci->dev, "The DSP is enabled on
> this platform, aborting probe\n");
> return -ENODEV;
> }
lenovo thinkpad carbon 6th gen - no sound after this patch, and this
patch should fix sound issue for it (not tested, just checking the
condition and pci attrs)
But what interesting is that I cannot remove snd_soc_skl module
without reboot (to adjust "pci_binding=1" so make sound works),
because kernel hang after short period doing it:
# rmmod snd_soc_skl_ssp_clk
# rmmod snd_soc_skl
WARN_ON triggered on rmmod:
Dec 30 19:29:38 WARNING: CPU: 0 PID: 22941 at
sound/hda/hdac_component.c:327 snd_hdac_acomp_exit+0x69/0x90
[snd_hda_core]
Dec 30 19:29:38 Modules linked in: snd_hda_intel snd_usb_audio
snd_usbmidi_lib snd_rawmidi snd_seq_device cdc_ether usbnet r8152 mii
hid_apple hid_generic usbhid hid thunderbolt tun
bluetooth ecdh_generic nf_conntrack_netlink nfnetlink xfrm_user
xfrm_algo xt_addrtype xt_conntrack br_netfilter iptable_mangle
xt_CHECKSUM iptable_nat joydev mousedev rmi_smbus rmi_c
ore ipt_MASQUERADE nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6
nf_defrag_ipv4 libcrc32c xt_tcpudp overlay bridge stp llc
iptable_filter ccm algif_aead cbc snd_soc_hdac_hdmi des_ge
neric zram arc4 lz4 lz4_compress cmac msr md4 algif_hash i915
snd_soc_dmic snd_soc_skl(-) iwlmvm snd_soc_skl_ipc snd_soc_sst_ipc
snd_soc_sst_dsp snd_hda_ext_core snd_soc_acpi_intel_m
atch snd_soc_acpi mac80211 snd_soc_core snd_compress iTCO_wdt ac97_bus
kvmgt iTCO_vendor_support intel_rapl snd_pcm_dmaengine vfio_mdev mdev
x86_pkg_temp_thermal uvcvideo intel_power
clamp coretemp vfio_iommu_type1 kvm_intel vfio snd_hda_codec
videobuf2_vmalloc i2c_algo_bit
Dec 30 19:29:38 videobuf2_memops iwlwifi videobuf2_v4l2
videobuf2_common snd_hda_core videodev drm_kms_helper tpm_crb kvm
nls_iso8859_1 snd_hwdep cfg80211 drm nls_cp437 snd_pcm irqb
ypass thinkpad_acpi intel_cstate intel_uncore nvram psmouse intel_gtt
e1000e snd_timer agpgart ledtrig_audio intel_rapl_perf syscopyarea snd
input_leds processor_thermal_device pcspk
r tpm_tis tpm_tis_core sysfillrect i2c_i801 media wmi_bmof
intel_wmi_thunderbolt tpm ucsi_acpi typec_ucsi mei_me int3403_thermal
sysimgblt rfkill mei fb_sys_fops typec intel_soc_dts_
iosf intel_pch_thermal rng_core soundcore battery ac
int340x_thermal_zone evdev mac_hid int3400_thermal acpi_thermal_rel
pcc_cpufreq vboxnetflt(OE) vboxnetadp(OE) vboxpci(OE) vboxdrv
(OE) crypto_user ip_tables x_tables ext4 crc32c_generic crc16 mbcache
jbd2 fscrypto algif_skcipher af_alg dm_crypt dm_mod crct10dif_pclmul
crc32_pclmul crc32c_intel ghash_clmulni_int
el serio_raw atkbd libps2 aesni_intel aes_x86_64 xhci_pci crypto_simd
cryptd xhci_hcd glue_helper
Dec 30 19:29:38 wmi i8042 serio vfat fat [last unloaded: snd_soc_skl_ssp_clk]
Dec 30 19:29:38 CPU: 0 PID: 22941 Comm: rmmod Tainted: G U OE
4.20.0-custom-06428-g00c569b567c7 #1
Dec 30 19:29:38 Hardware name: LENOVO 20KH006MRT/20KH006MRT, BIOS
N23ET50W (1.25 ) 06/25/2018
Dec 30 19:29:38 RIP: 0010:snd_hdac_acomp_exit+0x69/0x90 [snd_hda_core]
Dec 30 19:29:38 Code: 0d 83 5f c5 48 89 ef 31 c9 31 d2 48 c7 83 a0 04
00 00 00 00 00 00 48 c7 c6 80 6b ba c0 e8 4f 35 60 c5 31 c0 5b 5d c3
31 c0 c3 <0f> 0b 48 8b 50 08 48 85 d2 74 ae
48 8b 52 10 48 8b 38 e8 d0 a1 c5
Dec 30 19:29:38 RSP: 0018:a73f42b97de8 EFLAGS: 00010202
Dec 30 19:29:38 RAX: 94464d71e7f8 RBX: 94464a22c018 RCX:
Dec 30 19:29:38 RDX: 0001 RSI: RDI:
94464a22c018
Dec 30 19:29:38 RBP: 94464fa690b0 R08: 944651c02480 R09:
944651c024f8
Dec 30 19:29:38 R10: R11: 86e4a478 R12:
94464fa690b0
Dec 30 19:29:38 R13: c0b2e070 R14: 94464ffb7c60 R15:
dead0100
Dec 30 19:29:38 FS: 77983b80() GS:94465240()
knlGS:
Dec 30 19:29:38 CS: 0010 DS: ES: CR0: 80050033
Dec 30 19:29:38 CR2: 55784098 CR3: 000304682003 CR4:
003606f0
Dec 30 19:29:38 Call Trace:
Dec 30 19:29:38 skl_free+0x7e/0x90 [snd_soc_skl]
Dec 30 19:29:38 skl_remove+0x9f/0xb0 [snd_soc_skl]
Dec 30 19:29:38 pci_device_remove+0x3b/0xc0
Dec 30 19:29:38 device_release_dri
Re: load average always more then 1 on idle system with dyntick (just after boot)
On Tue, Mar 31, 2015 at 10:52:48PM +0300, Azat Khuzhin wrote: > Hi all, > > On one of machines [SUPERMICRO], after installing fresh kernel > (v4.0-rc5-25-g90a5a89), I noticed that loadavg always greater then 1. Still got the same for v4.0-2620-gb79013b. Cheers, Azat. -- 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: load average always more then 1 on idle system with dyntick (just after boot)
On Tue, Apr 14, 2015 at 11:54:24AM +0200, Peter Zijlstra wrote: > On Tue, Mar 31, 2015 at 10:52:48PM +0300, Azat Khuzhin wrote: > > Hi all, > > > > On one of machines [SUPERMICRO], after installing fresh kernel > > (v4.0-rc5-25-g90a5a89), I noticed that loadavg always greater then 1. > > > > I do a lot of digging and finally have more information on this issue: > > CONFIG_NO_HZ_IDLE=y # loadavg always > 1 > > CONFIG_HZ_PERIODIC=y # loadavg < 1 > > > > After this I tried to disable "nohz" at boot, to determine whether it is > > statically added code under #ifdef during compilation or not, so I added > > "nohz=off" to cmdline, and it helps! > > > > Also if you enable preemption loadavg is also < 1: > > CONFIG_PREEMPT_VOLUNTARY=y > > So you need CONFIG_PREEMPT=n and CONFIG_NO_HZ_IDLE=y for this to happen? Yep, CONFIG_PREEMPT_NONE=y and CONFIG_NO_HZ_IDLE=y > That's somewhat odd (and uncommon I think, most everybody has at least > VOLUNTARY enabled these days). This is not a big problem for me, I could enable VOLUNTARY, but I don't think that it will be useful for my workload. But I could be wrong. > I'll try to look over the code to see if I can find a preempt relation, > weird that. Thanks! -- 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] fs/sync.c : Add CAP_SYS_ADMIN checking before sync
On Thu, Apr 16, 2015 at 07:43:34PM +0800, Wuqixuan wrote:
> The process, supposed in one container, can't flush the metadata
> and data of the all host's partitions without CAP_SYS_ADMIN
> capability, like sys_mount is doing. The checking will prevent some
> vicious programs impacting IO sequnces of those partitions,
> particularly, the ones which can't be accessed in the container.
>
> Signed-off-by: Last Wu
> ---
> fs/sync.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/sync.c b/fs/sync.c
> index fbc98ee..9f07909 100644
> --- a/fs/sync.c
> +++ b/fs/sync.c
> @@ -103,6 +103,9 @@ SYSCALL_DEFINE0(sync)
> {
> int nowait = 0, wait = 1;
>
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
So after this patch I can't call sync as a regular user? (even without
containers).
But nothing in sync(2) says about special permissions for this.
--
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/
[PATCH v3] ext4: initialize multi-block allocator before checking block descriptors
With EXT4FS_DEBUG ext4_count_free_clusters() will call
ext4_read_block_bitmap() without s_group_info initialized, so we need to
initialize multi-block allocator before.
And we can't initialize multi-block allocator without group descriptors,
since it use them.
Also we need to install s_op before initializing multi-block allocator,
because in ext4_mb_init_backend() new inode is created.
Here is bt:
(gdb) bt
#0 ext4_get_group_info (group=0, sb=0x880079a1) at ext4.h:2430
#1 ext4_validate_block_bitmap (sb=sb@entry=0x880079a1,
desc=desc@entry=0x88005651, block_group=block_group@entry=0,
bh=bh@entry=0x88007bf2b2d8) at balloc.c:358
#2 0x81232202 in ext4_wait_block_bitmap
(sb=sb@entry=0x880079a1, block_group=block_group@entry=0,
bh=bh@entry=0x88007bf2b2d8) at balloc.c:476
#3 0x81232eaf in ext4_read_block_bitmap
(sb=sb@entry=0x880079a1, block_group=block_group@entry=0) at
balloc.c:489
#4 0x81232fc0 in ext4_count_free_clusters
(sb=sb@entry=0x880079a1) at balloc.c:665
#5 0x81259ffa in ext4_check_descriptors (first_not_zeroed=, sb=0x880079a1) at super.c:2143
#6 ext4_fill_super (sb=sb@entry=0x880079a1, data=,
data@entry=0x0 , silent=silent@entry=0)
at super.c:3851
#7 0x811b8340 in mount_bdev (fs_type=, flags=0,
dev_name=, data=0x0 ,
fill_super=fill_super@entry=0x812589c0 ) at
super.c:987
#8 0x8124ec35 in ext4_mount (fs_type=,
flags=, dev_name=, data=)
at super.c:5365
#9 0x811b8cf9 in mount_fs (type=type@entry=0x81c71840
, flags=flags@entry=0,
name=name@entry=0x880077a80c70 "/dev/loop4", data=data@entry=0x0
) at super.c:1090
#10 0x811d2ff3 in vfs_kern_mount (type=type@entry=0x81c71840
, flags=0,
name=name@entry=0x880077a80c70 "/dev/loop4", data=data@entry=0x0
) at namespace.c:813
#11 0x811d55de in do_new_mount (data=0x0 ,
name=0x880077a80c70 "/dev/loop4", mnt_flags=32,
flags=, fstype=0x880077a80ca0 "ext4-insane",
path=0x88007a5b1ed0) at namespace.c:2068
#12 do_mount (dev_name=0x880077a80c70 "/dev/loop4", dir_name=, type_page=0x880077a80ca0 "ext4-insane",
flags=, flags@entry=3236757504, data_page=0x0
) at namespace.c:2392
#13 0x811d6183 in SYSC_mount (data=0x0 ,
flags=3236757504, type=, dir_name=,
dev_name=0x7ffad9649c20 "/dev/loop4") at namespace.c:2586
#14 SyS_mount (dev_name=140715365800992, dir_name=,
type=, flags=3236757504, data=0) at namespace.c:2559
Signed-off-by: Azat Khuzhin
---
v2: ext4: initialize multi-block allocator after group descriptors loaded
v3: ext4: set s_op before initializing multi-block allocator
fs/ext4/super.c | 44 +++-
1 file changed, 23 insertions(+), 21 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 1f7784d..fc42ee0 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3848,16 +3848,34 @@ static int ext4_fill_super(struct super_block *sb, void
*data, int silent)
goto failed_mount2;
}
}
+
+ /*
+* set up enough so that it can read an inode
+*/
+ if (!test_opt(sb, NOLOAD) &&
+ EXT4_HAS_COMPAT_FEATURE(sb, EXT4_FEATURE_COMPAT_HAS_JOURNAL))
+ sb->s_op = &ext4_sops;
+ else
+ sb->s_op = &ext4_nojournal_sops;
+
+ ext4_ext_init(sb);
+ err = ext4_mb_init(sb);
+ if (err) {
+ ext4_msg(sb, KERN_ERR, "failed to initialize mballoc (%d)",
+err);
+ goto failed_mount2;
+ }
+
if (!ext4_check_descriptors(sb, &first_not_zeroed)) {
ext4_msg(sb, KERN_ERR, "group descriptors corrupted!");
- goto failed_mount2;
+ goto failed_mount2a;
}
if (EXT4_HAS_INCOMPAT_FEATURE(sb, EXT4_FEATURE_INCOMPAT_FLEX_BG))
if (!ext4_fill_flex_info(sb)) {
ext4_msg(sb, KERN_ERR,
"unable to initialize "
"flex_bg meta info!");
- goto failed_mount2;
+ goto failed_mount2a;
}
sbi->s_gdb_count = db_count;
@@ -3895,14 +3913,6 @@ static int ext4_fill_super(struct super_block *sb, void
*data, int silent)
sbi->s_stripe = ext4_get_stripe_size(sbi);
sbi->s_extent_max_zeroout_kb = 32;
- /*
-* set up enough so that it can read an inode
-*/
- if (!test_opt(sb, NOLOAD) &&
- EXT4_HAS_COMPAT_FEATURE(sb, EXT4_FEATURE_COMPAT_HAS_JOURNAL))
- sb->s_op = &ext4_sops;
- else
- sb->s_op = &ext4_nojournal_sops;
[PATCH v4] ext4: initialize multi-block allocator before checking block descriptors
With EXT4FS_DEBUG ext4_count_free_clusters() will call
ext4_read_block_bitmap() without s_group_info initialized, so we need to
initialize multi-block allocator before.
And dependencies that must be solved, to allow this:
- multi-block allocator needs in group descriptors
- need to install s_op before initializing multi-block allocator,
because in ext4_mb_init_backend() new inode is created.
- initialize number of group desc blocks (s_gdb_count) otherwise
number of clusters returned by ext4_free_clusters_after_init() is not correct.
(see ext4_bg_num_gdb_nometa())
Here is bt:
(gdb) bt
#0 ext4_get_group_info (group=0, sb=0x880079a1) at ext4.h:2430
#1 ext4_validate_block_bitmap (sb=sb@entry=0x880079a1,
desc=desc@entry=0x88005651, block_group=block_group@entry=0,
bh=bh@entry=0x88007bf2b2d8) at balloc.c:358
#2 0x81232202 in ext4_wait_block_bitmap
(sb=sb@entry=0x880079a1, block_group=block_group@entry=0,
bh=bh@entry=0x88007bf2b2d8) at balloc.c:476
#3 0x81232eaf in ext4_read_block_bitmap
(sb=sb@entry=0x880079a1, block_group=block_group@entry=0) at
balloc.c:489
#4 0x81232fc0 in ext4_count_free_clusters
(sb=sb@entry=0x880079a1) at balloc.c:665
#5 0x81259ffa in ext4_check_descriptors (first_not_zeroed=, sb=0x880079a1) at super.c:2143
#6 ext4_fill_super (sb=sb@entry=0x880079a1, data=,
data@entry=0x0 , silent=silent@entry=0)
at super.c:3851
#7 0x811b8340 in mount_bdev (fs_type=, flags=0,
dev_name=, data=0x0 ,
fill_super=fill_super@entry=0x812589c0 ) at
super.c:987
#8 0x8124ec35 in ext4_mount (fs_type=,
flags=, dev_name=, data=)
at super.c:5365
#9 0x811b8cf9 in mount_fs (type=type@entry=0x81c71840
, flags=flags@entry=0,
name=name@entry=0x880077a80c70 "/dev/loop4", data=data@entry=0x0
) at super.c:1090
#10 0x811d2ff3 in vfs_kern_mount (type=type@entry=0x81c71840
, flags=0,
name=name@entry=0x880077a80c70 "/dev/loop4", data=data@entry=0x0
) at namespace.c:813
#11 0x811d55de in do_new_mount (data=0x0 ,
name=0x880077a80c70 "/dev/loop4", mnt_flags=32,
flags=, fstype=0x880077a80ca0 "ext4-insane",
path=0x88007a5b1ed0) at namespace.c:2068
#12 do_mount (dev_name=0x880077a80c70 "/dev/loop4", dir_name=, type_page=0x880077a80ca0 "ext4-insane",
flags=, flags@entry=3236757504, data_page=0x0
) at namespace.c:2392
#13 0x811d6183 in SYSC_mount (data=0x0 ,
flags=3236757504, type=, dir_name=,
dev_name=0x7ffad9649c20 "/dev/loop4") at namespace.c:2586
#14 SyS_mount (dev_name=140715365800992, dir_name=,
type=, flags=3236757504, data=0) at namespace.c:2559
Signed-off-by: Azat Khuzhin
---
Link: http://marc.info/?l=linux-ext4&m=139493754530149&w=2
v5: initialize number of group desc blocks (s_gdb_count) otherwise
number of clusters returned by ext4_free_clusters_after_init() is not
correct.
fs/ext4/super.c | 51 +++
1 file changed, 27 insertions(+), 24 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index f3c6670..6f9e6fa 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3869,19 +3869,38 @@ static int ext4_fill_super(struct super_block *sb, void
*data, int silent)
goto failed_mount2;
}
}
+
+ /*
+* set up enough so that it can read an inode,
+* and create new inode for buddy allocator
+*/
+ sbi->s_gdb_count = db_count;
+ if (!test_opt(sb, NOLOAD) &&
+ EXT4_HAS_COMPAT_FEATURE(sb, EXT4_FEATURE_COMPAT_HAS_JOURNAL))
+ sb->s_op = &ext4_sops;
+ else
+ sb->s_op = &ext4_nojournal_sops;
+
+ ext4_ext_init(sb);
+ err = ext4_mb_init(sb);
+ if (err) {
+ ext4_msg(sb, KERN_ERR, "failed to initialize mballoc (%d)",
+err);
+ goto failed_mount2;
+ }
+
if (!ext4_check_descriptors(sb, &first_not_zeroed)) {
ext4_msg(sb, KERN_ERR, "group descriptors corrupted!");
- goto failed_mount2;
+ goto failed_mount2a;
}
if (EXT4_HAS_INCOMPAT_FEATURE(sb, EXT4_FEATURE_INCOMPAT_FLEX_BG))
if (!ext4_fill_flex_info(sb)) {
ext4_msg(sb, KERN_ERR,
"unable to initialize "
"flex_bg meta info!");
- goto failed_mount2;
+ goto failed_mount2a;
}
- sbi->s_gdb_count = db_count;
get_random_bytes(&sbi->s_next_generation, sizeof(u32));
spin_lock_init(&sbi->s_next_gen_lock);
@@ -3916,14 +3935,6 @@ stat
adjust /proc/PID/oom_score_adj with CAP_SYS_RESOURCE
Recently I needed in adjusting /proc/PID/oom_score_adj to disable oom killer, but I didn't want to add suid/or run from root that binary. I decided to use CAP_SYS_RESOURCE. However it didn't work. I gdb/strace/printk a lot, and finally found the reason, the process can't open this file for writing because pid_revalidate() change i_uid/i_gid for it to GLOBAL_ROOT_UID/GID. And to bypass this check I must to use CAP_DAC_OVERRIDE, which is not so good, because this will allow more capabilities than I need for that binary. Is this works by design, and/or is there another way to do this without suid/root? Thanks! -- Respectfully Azat Khuzhin -- 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/
[PATCH] perf probe: add '--demangle'/'--no-demangle'
You can't pass demangled name into "perf probe", because of special chars:
./perf probe -f -x /tmp/a.out 'foo(int)'
Semantic error :There is non-digit char in line number.
And you can't even pass without demangling (because it search symbol in
DSO with demangle=true):
./perf probe -f -x /tmp/a.out _Z3fooi
no symbols found in /tmp/a.out, maybe install a debug package?
However:
nm /tmp/a.out | grep foo
0040056d T _Z3fooi
After this patch, using the next command:
./perf probe -f --no-demangle -x /tmp/a.out _Z3fooi
probe will be successfully added.
Signed-off-by: Azat Khuzhin
---
tools/perf/builtin-probe.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index e8a66f9..7620f2e 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -325,6 +325,8 @@ int cmd_probe(int argc, const char **argv, const char
*prefix __maybe_unused)
opt_set_filter),
OPT_CALLBACK('x', "exec", NULL, "executable|path",
"target executable name or path", opt_set_target),
+ OPT_BOOLEAN(0, "demangle", &symbol_conf.demangle,
+ "Disable symbol demangling"),
OPT_END()
};
int ret;
--
1.8.4.rc3
--
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] ext4: drop unsed reclen variable from ext4_add_dirent_to_inline()
On Wed, Oct 30, 2013 at 6:55 PM, Theodore Ts'o wrote: > On Thu, Sep 19, 2013 at 12:17:30AM +0400, Azat Khuzhin wrote: >> Functions that need in it, already calculate reclen from namelen by >> themselves: >> - ext4_find_dest_de() >> - ext4_insert_dentry() >> >> Signed-off-by: Azat Khuzhin > > Applied, thanks. Thank you! But there is a typo in subject, s/unsed/unused/ could you fix or it, or tell me, and I will resend it? Thanks! > > - Ted -- Respectfully Azat Khuzhin -- 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/
[PATCH] ext4: fix ext4_count_free_clusters() with EXT4FS_DEBUG and bigalloc enabled
With bigalloc enabled we must use EXT4_CLUSTERS_PER_GROUP() instead of EXT4_BLOCKS_PER_GROUP() otherwise we will go beyond the allocated buffer. $ mount -t ext4 /dev/vde /vde [ 70.573993] EXT4-fs DEBUG (fs/ext4/mballoc.c, 2346): ext4_mb_alloc_groupinfo: [ 70.575174] allocated s_groupinfo array for 1 meta_bg's [ 70.576172] EXT4-fs DEBUG (fs/ext4/super.c, 2092): ext4_check_descriptors: [ 70.576972] Checking group descriptorsBUG: unable to handle kernel paging request at 88006ab56000 [ 72.463686] IP: [] __bitmap_weight+0x2a/0x7f [ 72.464168] PGD 295e067 PUD 2961067 PMD 7fa8e067 PTE 80006ab56060 [ 72.464738] Oops: [#1] SMP DEBUG_PAGEALLOC [ 72.465139] Modules linked in: [ 72.465402] CPU: 1 PID: 3560 Comm: mount Tainted: GW 3.14.0-rc2-00069-ge57bce1 #60 [ 72.466079] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 72.466505] task: 88007ce6c8a0 ti: 88006b7f task.ti: 88006b7f [ 72.466505] RIP: 0010:[] [] __bitmap_weight+0x2a/0x7f [ 72.466505] RSP: 0018:88006b7f1c00 EFLAGS: 00010206 [ 72.466505] RAX: RBX: 050a RCX: 0040 [ 72.466505] RDX: RSI: 0008 RDI: [ 72.466505] RBP: 88006b7f1c28 R08: 0002 R09: [ 72.466505] R10: babe R11: 0400 R12: 0008 [ 72.466505] R13: 0200 R14: 2000 R15: 88006ab55000 [ 72.466505] FS: 7f43ba1fa840() GS:88007f80() knlGS: [ 72.466505] CS: 0010 DS: ES: CR0: 8005003b [ 72.466505] CR2: 88006ab56000 CR3: 6b7e6000 CR4: 06e0 [ 72.466505] Stack: [ 72.466505] 88006ab65000 0001 [ 72.466505] 88006ab6f400 88006b7f1c58 81396bb8 0001 [ 72.466505] 88007b869a90 88006a48a000 88006b7f1c70 [ 72.466505] Call Trace: [ 72.466505] [] memweight+0x5f/0x8a [ 72.466505] [] ext4_count_free+0x13/0x21 [ 72.466505] [] ext4_count_free_clusters+0xdb/0x171 [ 72.466505] [] ext4_fill_super+0x117c/0x28ef [ 72.466505] [] ? vsnprintf+0x1c7/0x3f7 [ 72.466505] [] mount_bdev+0x145/0x19c [ 72.466505] [] ? ext4_calculate_overhead+0x2a1/0x2a1 [ 72.466505] [] ext4_mount+0x15/0x17 [ 72.466505] [] mount_fs+0x67/0x150 [ 72.466505] [] vfs_kern_mount+0x64/0xde [ 72.466505] [] do_mount+0x6fe/0x7f5 [ 72.466505] [] ? strndup_user+0x3a/0xd9 [ 72.466505] [] SyS_mount+0x85/0xbe [ 72.466505] [] tracesys+0xdd/0xe2 [ 72.466505] Code: c3 89 f0 b9 40 00 00 00 55 99 48 89 e5 41 57 f7 f9 41 56 49 89 ff 41 55 45 31 ed 41 54 41 89 f4 53 31 db 41 89 c6 45 39 ee 7e 10 <4b> 8b 3c ef 49 ff c5 e8 bf ff ff ff 01 c3 eb eb 31 c0 45 85 f6 [ 72.466505] RIP [] __bitmap_weight+0x2a/0x7f [ 72.466505] RSP [ 72.466505] CR2: 88006ab56000 [ 72.466505] ---[ end trace 7d051a08ae138573 ]--- Killed --- fs/ext4/balloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c index 6ea7b14..5c56785 100644 --- a/fs/ext4/balloc.c +++ b/fs/ext4/balloc.c @@ -667,7 +667,7 @@ ext4_fsblk_t ext4_count_free_clusters(struct super_block *sb) continue; x = ext4_count_free(bitmap_bh->b_data, - EXT4_BLOCKS_PER_GROUP(sb) / 8); + EXT4_CLUSTERS_PER_GROUP(sb) / 8); printk(KERN_DEBUG "group %u: stored = %d, counted = %u\n", i, ext4_free_group_clusters(sb, gdp), x); bitmap_count += x; -- 1.9.1 -- 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 07/13] vfs: add RENAME_WHITEOUT
d, whiteout->i_ino,
> + EXT4_FT_CHRDEV);
> + if (retval)
> + goto end_rename;
> + ext4_mark_inode_dirty(handle, whiteout);
> + }
> if (!new.bh) {
> retval = ext4_add_entry(handle, new.dentry, old.inode);
> if (retval)
> goto end_rename;
> } else {
> retval = ext4_setent(handle, &new,
> - old.inode->i_ino, old.de->file_type);
> + old.inode->i_ino, old_file_type);
> if (retval)
> goto end_rename;
> }
> @@ -3243,10 +3294,12 @@ static int ext4_rename(struct inode *old_dir, struct
> dentry *old_dentry,
> old.inode->i_ctime = ext4_current_time(old.inode);
> ext4_mark_inode_dirty(handle, old.inode);
>
> - /*
> - * ok, that's it
> - */
> - ext4_rename_delete(handle, &old);
> + if (!whiteout) {
> + /*
> + * ok, that's it
> + */
> + ext4_rename_delete(handle, &old);
> + }
>
> if (new.inode) {
> ext4_dec_count(handle, new.inode);
> @@ -3282,6 +3335,12 @@ end_rename:
> brelse(old.dir_bh);
> brelse(old.bh);
> brelse(new.bh);
> + if (whiteout) {
> + if (retval)
> + drop_nlink(whiteout);
> + unlock_new_inode(whiteout);
> + iput(whiteout);
> + }
> if (handle)
> ext4_journal_stop(handle);
> return retval;
> @@ -3403,22 +3462,26 @@ end_rename:
> return retval;
> }
>
> +static int ext4_rename(struct inode *old_dir, struct dentry *old_dentry,
> +struct inode *new_dir, struct dentry *new_dentry)
> +{
> + return ext4_simple_rename(old_dir, old_dentry, new_dir, new_dentry, 0);
> +}
> +
> static int ext4_rename2(struct inode *old_dir, struct dentry *old_dentry,
> struct inode *new_dir, struct dentry *new_dentry,
> unsigned int flags)
> {
> - if (flags & ~(RENAME_NOREPLACE | RENAME_EXCHANGE))
> + if (flags & ~(RENAME_NOREPLACE | RENAME_EXCHANGE | RENAME_WHITEOUT))
> return -EINVAL;
>
> if (flags & RENAME_EXCHANGE) {
> return ext4_cross_rename(old_dir, old_dentry,
>new_dir, new_dentry);
> }
> - /*
> - * Existence checking was done by the VFS, otherwise "RENAME_NOREPLACE"
> - * is equivalent to regular rename.
> - */
> - return ext4_rename(old_dir, old_dentry, new_dir, new_dentry);
> +
> + return ext4_simple_rename(old_dir, old_dentry,
> + new_dir, new_dentry, flags);
> }
>
> /*
> diff --git a/fs/namei.c b/fs/namei.c
> index 413d7c138e95..adaa73d91173 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -4186,12 +4186,16 @@ SYSCALL_DEFINE5(renameat2, int, olddfd, const char
> __user *, oldname,
> bool should_retry = false;
> int error;
>
> - if (flags & ~(RENAME_NOREPLACE | RENAME_EXCHANGE))
> + if (flags & ~(RENAME_NOREPLACE | RENAME_EXCHANGE | RENAME_WHITEOUT))
> return -EINVAL;
>
> - if ((flags & RENAME_NOREPLACE) && (flags & RENAME_EXCHANGE))
> + if ((flags & (RENAME_NOREPLACE | RENAME_WHITEOUT)) &&
> + (flags & RENAME_EXCHANGE))
> return -EINVAL;
>
> + if ((flags & RENAME_WHITEOUT) && !capable(CAP_MKNOD))
> + return -EPERM;
> +
> retry:
> from = user_path_parent(olddfd, oldname, &oldnd, lookup_flags);
> if (IS_ERR(from)) {
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 88ec7a2878bc..48d3bd908b5d 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -228,6 +228,13 @@ typedef void (dio_iodone_t)(struct kiocb *iocb, loff_t
> offset,
> #define WHITEOUT_DEV 0
>
> /*
> + * Whiteout is represented by a char device. The following constants define
> the
> + * mode and device number to use.
> + */
> +#define WHITEOUT_MODE 0
> +#define WHITEOUT_DEV 0
Quick note:
I suppose that there is no need in duplicating of WHITEOUT_{MODE,DEV}
Thanks.
> +
> +/*
> * This is the Inode Attributes structure, used for notify_change(). It
> * uses the above definitions as flags, to know which values have changed.
> * Also, in this manner, a Filesystem can look at only the values it cares
> diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
> index ca1a11bb4443..3735fa0a6784 100644
> --- a/include/uapi/linux/fs.h
> +++ b/include/uapi/linux/fs.h
> @@ -37,6 +37,7 @@
>
> #define RENAME_NOREPLACE (1 << 0)/* Don't overwrite target */
> #define RENAME_EXCHANGE (1 << 1)/* Exchange source and
> dest */
> +#define RENAME_WHITEOUT (1 << 2)/* Whiteout source */
>
> struct fstrim_range {
> __u64 start;
> --
> 1.8.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Respectfully
Azat Khuzhin
--
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: adjust /proc/PID/oom_score_adj with CAP_SYS_RESOURCE
On Sun, Oct 20, 2013 at 12:33 AM, Azat Khuzhin wrote:
> Recently I needed in adjusting /proc/PID/oom_score_adj to disable oom killer,
> but I didn't want to add suid/or run from root that binary.
>
> I decided to use CAP_SYS_RESOURCE. However it didn't work.
>
> I gdb/strace/printk a lot, and finally found the reason,
> the process can't open this file for writing because pid_revalidate()
> change i_uid/i_gid for it to GLOBAL_ROOT_UID/GID.
Here is some more information:
For binary with CAP_SYS_RESOURCE we have
Breakpoint 17, pid_revalidate
(gdb) p task->mm->flags
$85 = 204
(gdb) p (task->mm->flags & 3)
$86 = 0
(gdb) p (task->mm->flags & 3) > 1 ? 2 : 0
$87 = 0
For binary without:
Breakpoint 17, pid_revalidate
(gdb) p task->mm->flags
$85 = 205
(gdb) p (task->mm->flags & 3)
$86 = 1
(gdb) p (task->mm->flags & 3) > 1 ? 2 : 1
$87 = 1
(Where 3 is MMF_DUMPABLE_MASK.)
In pid_revalidate() checks does $87 != 0, if so, set i_{uid,gid} from
cred, otherwise set it to 0.
And that's why process can open "oom_score_adj" without capabilities
(but can't write to it)
> And to bypass this check I must to use CAP_DAC_OVERRIDE, which is not so good,
> because this will allow more capabilities than I need for that binary.
>
> Is this works by design,
> and/or is there another way to do this without suid/root?
>
> Thanks!
>
> --
> Respectfully
> Azat Khuzhin
--
Respectfully
Azat Khuzhin
--
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/
kprobe: "BUG: unable to handle kernel paging request"
With some kernel's configuration there is such messages in dmesg in different places while using kprobes. I investigated this and founded that it reproduced with https://gist.github.com/azat/7078890#file-config-3-12-0-rc5-deb And not reproduced with https://gist.github.com/azat/7078890#file-config-3-12-0-rc5-worked-kprobe I used the next script for testing https://gist.github.com/azat/7078890#file-ktap-sh Here is the initial email log with Jovi (ktap author): http://www.freelists.org/post/ktap/BUG-unable-to-handle-kernel-paging-request-after-ktap-script-to-trace-SyS-write If I can help, please let me know! Thanks! -- Respectfully Azat Khuzhin -- 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: kprobe: "BUG: unable to handle kernel paging request"
On Sat, Oct 26, 2013 at 1:01 AM, Azat Khuzhin wrote: > With some kernel's configuration there is such messages in dmesg in > different places while using kprobes. > > I investigated this and founded that it reproduced with > https://gist.github.com/azat/7078890#file-config-3-12-0-rc5-deb > And not reproduced with > https://gist.github.com/azat/7078890#file-config-3-12-0-rc5-worked-kprobe I reduced difference between this two configs, and the new one with not worked kprobe is here: https://gist.github.com/azat/7078890#file-config-3-12-0-rc5-dont-worked-kprobe The only thing I changed in "make menuconfig" is preemption model, from CONFIG_PREEMPT_VOLUNTARY(good) to CONFIG_PREEMPT(bad) U=https://gist.github.com/azat/7078890/raw/ diff -u0 <(curl -s $U/8268502680c9b1c5924ce6bf45dd08381bc9ddb3/config-3.12.0-rc5%2Bdont-worked-kprobe) <(curl -s $U/b7a9367506fa1c9598f5752c045cff582c3588ba/config-3.12.0-rc5%2Bworked-kprobe) --- /dev/fd/63 2013-10-26 20:35:00.679801733 +0400 +++ /dev/fd/62 2013-10-26 20:35:00.679801733 +0400 @@ -128,2 +128,2 @@ -CONFIG_TREE_PREEMPT_RCU=y -CONFIG_PREEMPT_RCU=y +CONFIG_TREE_RCU=y +# CONFIG_PREEMPT_RCU is not set @@ -137 +136,0 @@ -# CONFIG_RCU_BOOST is not set @@ -224,0 +224 @@ +CONFIG_OPTPROBES=y @@ -332 +332,5 @@ -CONFIG_UNINLINE_SPIN_UNLOCK=y +CONFIG_INLINE_SPIN_UNLOCK_IRQ=y +CONFIG_INLINE_READ_UNLOCK=y +CONFIG_INLINE_READ_UNLOCK_IRQ=y +CONFIG_INLINE_WRITE_UNLOCK=y +CONFIG_INLINE_WRITE_UNLOCK_IRQ=y @@ -378,2 +382,2 @@ -# CONFIG_PREEMPT_VOLUNTARY is not set -CONFIG_PREEMPT=y +CONFIG_PREEMPT_VOLUNTARY=y +# CONFIG_PREEMPT is not set @@ -3547,0 +3552 @@ +# CONFIG_DRM_I810 is not set @@ -5047 +5051,0 @@ -CONFIG_DEBUG_PREEMPT=y @@ -5075 +5078,0 @@ -# CONFIG_PROVE_RCU_DELAY is not set @@ -5079 +5081,0 @@ -CONFIG_RCU_CPU_STALL_VERBOSE=y @@ -5111 +5112,0 @@ -# CONFIG_PREEMPT_TRACER is not set > > I used the next script for testing > https://gist.github.com/azat/7078890#file-ktap-sh > > Here is the initial email log with Jovi (ktap author): > http://www.freelists.org/post/ktap/BUG-unable-to-handle-kernel-paging-request-after-ktap-script-to-trace-SyS-write > > If I can help, please let me know! > Thanks! > > -- > Respectfully > Azat Khuzhin -- Respectfully Azat Khuzhin -- 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/
[PATCH] ext4: initialize multi-block allocator before checking block descriptors
with EXT4FS_DEBUG ext4_count_free_clusters() will call
ext4_read_block_bitmap() without s_group_info initialized.
Here is bt:
(gdb) bt
#0 ext4_get_group_info (group=0, sb=0x880079a1) at ext4.h:2430
#1 ext4_validate_block_bitmap (sb=sb@entry=0x880079a1,
desc=desc@entry=0x88005651, block_group=block_group@entry=0,
bh=bh@entry=0x88007bf2b2d8) at balloc.c:358
#2 0x81232202 in ext4_wait_block_bitmap
(sb=sb@entry=0x880079a1, block_group=block_group@entry=0,
bh=bh@entry=0x88007bf2b2d8) at balloc.c:476
#3 0x81232eaf in ext4_read_block_bitmap
(sb=sb@entry=0x880079a1, block_group=block_group@entry=0) at
balloc.c:489
#4 0x81232fc0 in ext4_count_free_clusters
(sb=sb@entry=0x880079a1) at balloc.c:665
#5 0x81259ffa in ext4_check_descriptors (first_not_zeroed=, sb=0x880079a1) at super.c:2143
#6 ext4_fill_super (sb=sb@entry=0x880079a1, data=,
data@entry=0x0 , silent=silent@entry=0)
at super.c:3851
#7 0x811b8340 in mount_bdev (fs_type=, flags=0,
dev_name=, data=0x0 ,
fill_super=fill_super@entry=0x812589c0 ) at
super.c:987
#8 0x8124ec35 in ext4_mount (fs_type=,
flags=, dev_name=, data=)
at super.c:5365
#9 0x811b8cf9 in mount_fs (type=type@entry=0x81c71840
, flags=flags@entry=0,
name=name@entry=0x880077a80c70 "/dev/loop4", data=data@entry=0x0
) at super.c:1090
#10 0x811d2ff3 in vfs_kern_mount (type=type@entry=0x81c71840
, flags=0,
name=name@entry=0x880077a80c70 "/dev/loop4", data=data@entry=0x0
) at namespace.c:813
#11 0x811d55de in do_new_mount (data=0x0 ,
name=0x880077a80c70 "/dev/loop4", mnt_flags=32,
flags=, fstype=0x880077a80ca0 "ext4-insane",
path=0x88007a5b1ed0) at namespace.c:2068
#12 do_mount (dev_name=0x880077a80c70 "/dev/loop4", dir_name=, type_page=0x880077a80ca0 "ext4-insane",
flags=, flags@entry=3236757504, data_page=0x0
) at namespace.c:2392
#13 0x811d6183 in SYSC_mount (data=0x0 ,
flags=3236757504, type=, dir_name=,
dev_name=0x7ffad9649c20 "/dev/loop4") at namespace.c:2586
#14 SyS_mount (dev_name=140715365800992, dir_name=,
type=, flags=3236757504, data=0) at namespace.c:2559
Signed-off-by: Azat Khuzhin
---
fs/ext4/super.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 1f7784d..7e8c5e4 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3838,6 +3838,14 @@ static int ext4_fill_super(struct super_block *sb, void
*data, int silent)
bgl_lock_init(sbi->s_blockgroup_lock);
+ ext4_ext_init(sb);
+ err = ext4_mb_init(sb);
+ if (err) {
+ ext4_msg(sb, KERN_ERR, "failed to initialize mballoc (%d)",
+err);
+ goto failed_mount;
+ }
+
for (i = 0; i < db_count; i++) {
block = descriptor_loc(sb, logical_sb_block, i);
sbi->s_group_desc[i] = sb_bread(sb, block);
@@ -4094,14 +4102,6 @@ no_journal:
goto failed_mount4a;
}
- ext4_ext_init(sb);
- err = ext4_mb_init(sb);
- if (err) {
- ext4_msg(sb, KERN_ERR, "failed to initialize mballoc (%d)",
-err);
- goto failed_mount5;
- }
-
err = ext4_register_li_request(sb, first_not_zeroed);
if (err)
goto failed_mount6;
@@ -4175,9 +4175,6 @@ failed_mount8:
failed_mount7:
ext4_unregister_li_request(sb);
failed_mount6:
- ext4_mb_release(sb);
-failed_mount5:
- ext4_ext_release(sb);
ext4_release_system_zone(sb);
failed_mount4a:
dput(sb->s_root);
@@ -4207,7 +4204,10 @@ failed_mount2:
for (i = 0; i < db_count; i++)
brelse(sbi->s_group_desc[i]);
ext4_kvfree(sbi->s_group_desc);
+
+ ext4_mb_release(sb);
failed_mount:
+ ext4_ext_release(sb);
if (sbi->s_chksum_driver)
crypto_free_shash(sbi->s_chksum_driver);
if (sbi->s_proc) {
--
1.8.5.2
--
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 vfs 1/2] lib: implement ptrset
On Thu, Nov 13, 2014 at 05:09:27PM -0500, Tejun Heo wrote:
> +int ptrset_add(void *ptr, struct ptrset *set, gfp_t gfp)
> +{
> + struct ptrset_elem *elem;
> + struct rb_node *parent, **slot;
> +
> + elem = kmalloc(sizeof(*elem), gfp);
> + if (!elem && !in_interrupt()) /* see ptrset_preload() */
> + elem = this_cpu_xchg(ptrset_preload_elem, NULL);
> + if (!elem)
> + return -ENOMEM;
> + elem->ptr = ptr;
> +
> + if (ptrset_find_slot(elem->ptr, set, &slot, &parent)) {
> + kfree(elem);
> + return -EEXIST;
> + }
Maybe allocation *after* ptrset_find_slot() will be better?
This will avoid extra kmalloc/kfree if such ptr already exist (and also
will avoid ENOMEM for such cases).
--
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 RFC v2 2/2] vfs: add O_NOCMTIME
On Fri, May 15, 2015 at 02:23:48PM -0700, Zach Brown wrote: > Add a O_NOCMTIME flag which prevents inode time updates on writes and > can greatly reduce the IO overhead of writes to allocated and > initialized regions of files. > --- a/include/linux/fs.h > +++ b/include/linux/fs.h You may also want to resolve this: /* * Don't update ctime and mtime. * * Currently a special hack for the XFS open_by_handle ioctl, but we'll * hopefully graduate it to a proper O_CMTIME flag supported by open(2) soon. */ #define FMODE_NOCMTIME ((__force fmode_t)0x800) -- 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/
[tip:perf/urgent] perf probe: Add '--demangle'/'--no-demangle'
Commit-ID: 35e17b2450e09968f9702d4048c228199af171bc
Gitweb: http://git.kernel.org/tip/35e17b2450e09968f9702d4048c228199af171bc
Author: Azat Khuzhin
AuthorDate: Mon, 28 Oct 2013 12:04:24 +0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 14 Nov 2013 16:06:28 -0300
perf probe: Add '--demangle'/'--no-demangle'
You can't pass demangled name into "perf probe", because of special chars:
./perf probe -f -x /tmp/a.out 'foo(int)'
Semantic error :There is non-digit char in line number.
And you can't even pass without demangling (because it search symbol in
DSO with demangle=true):
./perf probe -f -x /tmp/a.out _Z3fooi
no symbols found in /tmp/a.out, maybe install a debug package?
However:
nm /tmp/a.out | grep foo
0040056d T _Z3fooi
After this patch, using the next command:
./perf probe -f --no-demangle -x /tmp/a.out _Z3fooi
probe will be successfully added.
Signed-off-by: Azat Khuzhin
Cc: Ingo Molnar
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1382947464-31266-1-git-send-email-a3at.m...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-probe.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index 89acc17..6ea9e85 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -325,6 +325,8 @@ int cmd_probe(int argc, const char **argv, const char
*prefix __maybe_unused)
opt_set_filter),
OPT_CALLBACK('x', "exec", NULL, "executable|path",
"target executable name or path", opt_set_target),
+ OPT_BOOLEAN(0, "demangle", &symbol_conf.demangle,
+ "Disable symbol demangling"),
OPT_END()
};
int ret;
--
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/
