Re: 4.2 kernel trace when hot unplug a mounted USB/SATA/MMC devices with ext2/ext3/ext4 file system
On Mon, Aug 24, 2015 at 02:20:07PM -0700, Duc Dang wrote: For more information. We tested kernel at commit 5f80f62ada ext4: remove useless condition in if statement. (right before your commit) and still saw the issue. df3305156f989339529b3d6744b898d498fb1f7b [media] v4l: xilinx: Add Xilinx Video IP core 08439fec266c3cc5702953b4f54bdf5649357de0 ext4: remove block_device_ejected 5f80f62adae2a2920781a847805d34b36b323f7d ext4: remove useless condition in if statement. c9bca8b33118573da9b7ac2ea21947a8e4d287dd [media] v4l: of: Add v4l2_of_parse_link() function Further more, the issue does not happen with 3.19-rc7 but happens with 4.00-rc1 Thanks for the report. Does it happen with commit aad653 block: discard bdi_unregister() in favour of bdi_destroy(), either cherry picked or the whole tree at that version? -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4.2 kernel trace when hot unplug a mounted USB/SATA/MMC devices with ext2/ext3/ext4 file system
On Sat, Aug 15, 2015 at 1:58 AM, Christoph Hellwig h...@lst.de wrote: On Fri, Aug 14, 2015 at 05:52:44PM -0700, Duc Dang wrote: The commit 08439fec26 ext4: remove block_device_ejected only causes issue with ext4 and trying reverting it helps our test passes with ext4. But how about the same issue with ext2/ext3? I tried to fix the underlying issue, but I either failed to fully fixed it or someone regressed it. Can you if rev 08439fec26 on it's own works to see if I missed a case or it was regressed later? For more information. We tested kernel at commit 5f80f62ada ext4: remove useless condition in if statement. (right before your commit) and still saw the issue. df3305156f989339529b3d6744b898d498fb1f7b [media] v4l: xilinx: Add Xilinx Video IP core 08439fec266c3cc5702953b4f54bdf5649357de0 ext4: remove block_device_ejected 5f80f62adae2a2920781a847805d34b36b323f7d ext4: remove useless condition in if statement. c9bca8b33118573da9b7ac2ea21947a8e4d287dd [media] v4l: of: Add v4l2_of_parse_link() function Further more, the issue does not happen with 3.19-rc7 but happens with 4.00-rc1 -- Regards, Duc Dang. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4.2 kernel trace when hot unplug a mounted USB/SATA/MMC devices with ext2/ext3/ext4 file system
On Fri, Aug 14, 2015 at 05:52:44PM -0700, Duc Dang wrote: The commit 08439fec26 ext4: remove block_device_ejected only causes issue with ext4 and trying reverting it helps our test passes with ext4. But how about the same issue with ext2/ext3? I tried to fix the underlying issue, but I either failed to fully fixed it or someone regressed it. Can you if rev 08439fec26 on it's own works to see if I missed a case or it was regressed later? -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4.2 kernel trace when hot unplug a mounted USB/SATA/MMC devices with ext2/ext3/ext4 file system
On Thu 13-08-15 09:01:28, Darrick J. Wong wrote: On Wed, Aug 12, 2015 at 08:17:28PM -0700, Duc Dang wrote: Hi Theodore, Andreas, Jan, Andrew and All, We are seeing kernel trace when we disconnect an USB/SATA/MMC devices that has its ext2/ext3/ext4 partition currently mounted. These traces are seen with kernel 4.2-rc5 on APM Arm64 X-Gene platforms. Similar issue also happens on an x86 machine (Lenovo T420s running Fedora Core 22 (Linux 4.1.x)) Sounds like this issue: https://bugzilla.kernel.org/show_bug.cgi?id=101011 Hum, the above bug mentions that at least for ext4 this is a regression caused by commit 08439fec26 ext4: remove block_device_ejected from Christoph, let's add him to CC. The assumption of the commit is that bdi-dev never goes away so there's no point in checking it but these guys are apparently able to make bdi go away before fs is done with it... Any idea Christoph? Honza We also tested with xfs kernel and kernel complains with some error message but there is no trace: usb 1-1: USB disconnect, device number 3 XFS (sda1): Unmounting Filesystem XFS (sda1): metadata I/O error: block 0x1ddc12 (xlog_iodone) error 19 numblks 64 XFS (sda1): xfs_do_force_shutdown(0x2) called from line 1180 of file /projects/svdc/P4wsIPCSW/buildsw_shadowcat_2_03/shadowcat/linux/fs/xfs/xfs_log.c. Return address = 0xffc0003aa8d8 XFS (sda1): Log I/O Error Detected. Shutting down filesystem XFS (sda1): Unable to update superblock counters. Freespace may not be correct on next mount. XFS (sda1): xfs_log_force: error -5 returned. XFS (sda1): Please umount the filesystem and rectify the problem(s) Below are traces for each case. Do you aware of this issue and is there a fix for it? CASE 1: SATA with ext2 partition: EXT2-fs (sda1): previous I/O error to superblock detected Unable to handle kernel paging request at virtual address 1ff256000 pgd = ffc0e784b000 [1ff256000] *pgd=, *pud= Internal error: Oops: 9605 [#1] PREEMPT SMP Modules linked in: CPU: 4 PID: 1484 Comm: umount Not tainted 4.1.0-xgene_sw_2.03.05-beta_rc_pm #1 Hardware name: APM X-Gene Mustang board (DT) task: ffc1ed5d3840 ti: ffc0e79dc000 task.ti: ffc0e79dc000 PC is at __percpu_counter_add+0x2c/0x10c LR is at account_page_dirtied+0x78/0x12c pc : [ffc00043666c] lr : [ffc000147180] pstate: 81c5 sp : ffc0e79dfc40 x29: ffc0e79dfc40 x28: ffc0e79dc000 x27: ffc000927000 x26: 0027 x25: 011a x24: 0015 x23: 8000 x22: 0140 x21: ffc000d33000 x20: ffc1f6440fb8 x19: ffbec7b3e500 x18: x17: 007f8d95bfd0 x16: ffc0001dfad0 x15: 003b9aca x14: 0ffe x13: 0020 x12: 0101010101010101 x11: 0174 x10: 0006 x9 : ffc1fff1e35c x8 : 746564206b636f6c x7 : ffc000d33618 x6 : 0001ff256000 x5 : ffc0e79dfc40 x4 : ffc0e79dc000 x3 : x2 : 0020 x1 : 0001 x0 : 0001ff256000 Process umount (pid: 1484, stack limit = 0xffc0e79dc020) Stack: (0xffc0e79dfc40 to 0xffc0e79e) fc40: e79dfc70 ffc0 00147180 ffc0 c7b3e500 ffbe f6440f78 ffc1 fc60: e79dfc70 ffc0 0014716c ffc0 e79dfcb0 ffc0 001ccd7c ffc0 fc80: c7b3e500 ffbe f6b28f48 ffc1 f6b28f60 ffc1 e79dfca0 ffc0 fca0: f6b28f48 ffc1 e79dfd00 ffc0 001cdfd4 ffc0 fcc0: c7b3e500 ffbe ecf94400 ffc1 ee6022d8 ffc0 fce0: 8000 00226674 ffc0 e79dfd20 ffc0 fd00: e79dfd20 ffc0 0022ac84 ffc0 f6ff7000 ffc1 ecf94400 ffc1 fd20: e79dfd50 ffc0 0022ad0c ffc0 f677e380 ffc1 ecf94400 ffc1 fd40: f6ff7000 ffc1 ed5d3840 ffc1 e79dfd90 ffc0 001cb0c4 ffc0 fd60: f6ff7000 ffc1 f6ff70a8 ffc1 00946080 ffc0 001b5ff0 ffc0 fd80: f6ff7000 ffc1 e79dfdb0 ffc0 001a05e0 ffc0 fda0: f6ff7000 ffc1 0083 e79dfde0 ffc0 001a0958 ffc0 fdc0: f6b28d00 ffc1 0083 00db9000 ffc0 0015 fde0: e79dfe10 ffc0 001a0c68 ffc0 f6ff7000 ffc1 00d511e8 ffc0 fe00: 00db9000 ffc0 00d511e8 ffc0 e79dfe30 ffc0 001a1168 ffc0 fe20: f6ff7000 ffc1 e79dfe50 ffc0 001bcef0 ffc0 fe40: f6c8b080 ffc1 0015 e79dfe70 ffc0 001bcf94 ffc0 fe60: ed5d4190 ffc1 90a791c8 007f e79dfe80 ffc0 000ce47c ffc0 fe80: e79dfeb0 ffc0 00089800 ffc0 000c 79a5e4f0 0055 fea0: 90a791c8 007f dc5d82a0 007f 00085b54
Re: 4.2 kernel trace when hot unplug a mounted USB/SATA/MMC devices with ext2/ext3/ext4 file system
On Fri, Aug 14, 2015 at 1:09 AM, Jan Kara j...@suse.cz wrote: On Thu 13-08-15 09:01:28, Darrick J. Wong wrote: On Wed, Aug 12, 2015 at 08:17:28PM -0700, Duc Dang wrote: Hi Theodore, Andreas, Jan, Andrew and All, We are seeing kernel trace when we disconnect an USB/SATA/MMC devices that has its ext2/ext3/ext4 partition currently mounted. These traces are seen with kernel 4.2-rc5 on APM Arm64 X-Gene platforms. Similar issue also happens on an x86 machine (Lenovo T420s running Fedora Core 22 (Linux 4.1.x)) Sounds like this issue: https://bugzilla.kernel.org/show_bug.cgi?id=101011 Hum, the above bug mentions that at least for ext4 this is a regression caused by commit 08439fec26 ext4: remove block_device_ejected from Christoph, let's add him to CC. The assumption of the commit is that bdi-dev never goes away so there's no point in checking it but these guys are apparently able to make bdi go away before fs is done with it... Any idea Christoph? The commit 08439fec26 ext4: remove block_device_ejected only causes issue with ext4 and trying reverting it helps our test passes with ext4. But how about the same issue with ext2/ext3? Honza We also tested with xfs kernel and kernel complains with some error message but there is no trace: usb 1-1: USB disconnect, device number 3 XFS (sda1): Unmounting Filesystem XFS (sda1): metadata I/O error: block 0x1ddc12 (xlog_iodone) error 19 numblks 64 XFS (sda1): xfs_do_force_shutdown(0x2) called from line 1180 of file /projects/svdc/P4wsIPCSW/buildsw_shadowcat_2_03/shadowcat/linux/fs/xfs/xfs_log.c. Return address = 0xffc0003aa8d8 XFS (sda1): Log I/O Error Detected. Shutting down filesystem XFS (sda1): Unable to update superblock counters. Freespace may not be correct on next mount. XFS (sda1): xfs_log_force: error -5 returned. XFS (sda1): Please umount the filesystem and rectify the problem(s) Below are traces for each case. Do you aware of this issue and is there a fix for it? CASE 1: SATA with ext2 partition: EXT2-fs (sda1): previous I/O error to superblock detected Unable to handle kernel paging request at virtual address 1ff256000 pgd = ffc0e784b000 [1ff256000] *pgd=, *pud= Internal error: Oops: 9605 [#1] PREEMPT SMP Modules linked in: CPU: 4 PID: 1484 Comm: umount Not tainted 4.1.0-xgene_sw_2.03.05-beta_rc_pm #1 Hardware name: APM X-Gene Mustang board (DT) task: ffc1ed5d3840 ti: ffc0e79dc000 task.ti: ffc0e79dc000 PC is at __percpu_counter_add+0x2c/0x10c LR is at account_page_dirtied+0x78/0x12c pc : [ffc00043666c] lr : [ffc000147180] pstate: 81c5 sp : ffc0e79dfc40 x29: ffc0e79dfc40 x28: ffc0e79dc000 x27: ffc000927000 x26: 0027 x25: 011a x24: 0015 x23: 8000 x22: 0140 x21: ffc000d33000 x20: ffc1f6440fb8 x19: ffbec7b3e500 x18: x17: 007f8d95bfd0 x16: ffc0001dfad0 x15: 003b9aca x14: 0ffe x13: 0020 x12: 0101010101010101 x11: 0174 x10: 0006 x9 : ffc1fff1e35c x8 : 746564206b636f6c x7 : ffc000d33618 x6 : 0001ff256000 x5 : ffc0e79dfc40 x4 : ffc0e79dc000 x3 : x2 : 0020 x1 : 0001 x0 : 0001ff256000 Process umount (pid: 1484, stack limit = 0xffc0e79dc020) Stack: (0xffc0e79dfc40 to 0xffc0e79e) fc40: e79dfc70 ffc0 00147180 ffc0 c7b3e500 ffbe f6440f78 ffc1 fc60: e79dfc70 ffc0 0014716c ffc0 e79dfcb0 ffc0 001ccd7c ffc0 fc80: c7b3e500 ffbe f6b28f48 ffc1 f6b28f60 ffc1 e79dfca0 ffc0 fca0: f6b28f48 ffc1 e79dfd00 ffc0 001cdfd4 ffc0 fcc0: c7b3e500 ffbe ecf94400 ffc1 ee6022d8 ffc0 fce0: 8000 00226674 ffc0 e79dfd20 ffc0 fd00: e79dfd20 ffc0 0022ac84 ffc0 f6ff7000 ffc1 ecf94400 ffc1 fd20: e79dfd50 ffc0 0022ad0c ffc0 f677e380 ffc1 ecf94400 ffc1 fd40: f6ff7000 ffc1 ed5d3840 ffc1 e79dfd90 ffc0 001cb0c4 ffc0 fd60: f6ff7000 ffc1 f6ff70a8 ffc1 00946080 ffc0 001b5ff0 ffc0 fd80: f6ff7000 ffc1 e79dfdb0 ffc0 001a05e0 ffc0 fda0: f6ff7000 ffc1 0083 e79dfde0 ffc0 001a0958 ffc0 fdc0: f6b28d00 ffc1 0083 00db9000 ffc0 0015 fde0: e79dfe10 ffc0 001a0c68 ffc0 f6ff7000 ffc1 00d511e8 ffc0 fe00: 00db9000 ffc0 00d511e8 ffc0 e79dfe30 ffc0 001a1168 ffc0 fe20: f6ff7000 ffc1 e79dfe50 ffc0 001bcef0 ffc0 fe40: f6c8b080 ffc1 0015 e79dfe70 ffc0 001bcf94
Re: 4.2 kernel trace when hot unplug a mounted USB/SATA/MMC devices with ext2/ext3/ext4 file system
On Wed, Aug 12, 2015 at 08:17:28PM -0700, Duc Dang wrote: Hi Theodore, Andreas, Jan, Andrew and All, We are seeing kernel trace when we disconnect an USB/SATA/MMC devices that has its ext2/ext3/ext4 partition currently mounted. These traces are seen with kernel 4.2-rc5 on APM Arm64 X-Gene platforms. Similar issue also happens on an x86 machine (Lenovo T420s running Fedora Core 22 (Linux 4.1.x)) Sounds like this issue: https://bugzilla.kernel.org/show_bug.cgi?id=101011 --D We also tested with xfs kernel and kernel complains with some error message but there is no trace: usb 1-1: USB disconnect, device number 3 XFS (sda1): Unmounting Filesystem XFS (sda1): metadata I/O error: block 0x1ddc12 (xlog_iodone) error 19 numblks 64 XFS (sda1): xfs_do_force_shutdown(0x2) called from line 1180 of file /projects/svdc/P4wsIPCSW/buildsw_shadowcat_2_03/shadowcat/linux/fs/xfs/xfs_log.c. Return address = 0xffc0003aa8d8 XFS (sda1): Log I/O Error Detected. Shutting down filesystem XFS (sda1): Unable to update superblock counters. Freespace may not be correct on next mount. XFS (sda1): xfs_log_force: error -5 returned. XFS (sda1): Please umount the filesystem and rectify the problem(s) Below are traces for each case. Do you aware of this issue and is there a fix for it? CASE 1: SATA with ext2 partition: EXT2-fs (sda1): previous I/O error to superblock detected Unable to handle kernel paging request at virtual address 1ff256000 pgd = ffc0e784b000 [1ff256000] *pgd=, *pud= Internal error: Oops: 9605 [#1] PREEMPT SMP Modules linked in: CPU: 4 PID: 1484 Comm: umount Not tainted 4.1.0-xgene_sw_2.03.05-beta_rc_pm #1 Hardware name: APM X-Gene Mustang board (DT) task: ffc1ed5d3840 ti: ffc0e79dc000 task.ti: ffc0e79dc000 PC is at __percpu_counter_add+0x2c/0x10c LR is at account_page_dirtied+0x78/0x12c pc : [ffc00043666c] lr : [ffc000147180] pstate: 81c5 sp : ffc0e79dfc40 x29: ffc0e79dfc40 x28: ffc0e79dc000 x27: ffc000927000 x26: 0027 x25: 011a x24: 0015 x23: 8000 x22: 0140 x21: ffc000d33000 x20: ffc1f6440fb8 x19: ffbec7b3e500 x18: x17: 007f8d95bfd0 x16: ffc0001dfad0 x15: 003b9aca x14: 0ffe x13: 0020 x12: 0101010101010101 x11: 0174 x10: 0006 x9 : ffc1fff1e35c x8 : 746564206b636f6c x7 : ffc000d33618 x6 : 0001ff256000 x5 : ffc0e79dfc40 x4 : ffc0e79dc000 x3 : x2 : 0020 x1 : 0001 x0 : 0001ff256000 Process umount (pid: 1484, stack limit = 0xffc0e79dc020) Stack: (0xffc0e79dfc40 to 0xffc0e79e) fc40: e79dfc70 ffc0 00147180 ffc0 c7b3e500 ffbe f6440f78 ffc1 fc60: e79dfc70 ffc0 0014716c ffc0 e79dfcb0 ffc0 001ccd7c ffc0 fc80: c7b3e500 ffbe f6b28f48 ffc1 f6b28f60 ffc1 e79dfca0 ffc0 fca0: f6b28f48 ffc1 e79dfd00 ffc0 001cdfd4 ffc0 fcc0: c7b3e500 ffbe ecf94400 ffc1 ee6022d8 ffc0 fce0: 8000 00226674 ffc0 e79dfd20 ffc0 fd00: e79dfd20 ffc0 0022ac84 ffc0 f6ff7000 ffc1 ecf94400 ffc1 fd20: e79dfd50 ffc0 0022ad0c ffc0 f677e380 ffc1 ecf94400 ffc1 fd40: f6ff7000 ffc1 ed5d3840 ffc1 e79dfd90 ffc0 001cb0c4 ffc0 fd60: f6ff7000 ffc1 f6ff70a8 ffc1 00946080 ffc0 001b5ff0 ffc0 fd80: f6ff7000 ffc1 e79dfdb0 ffc0 001a05e0 ffc0 fda0: f6ff7000 ffc1 0083 e79dfde0 ffc0 001a0958 ffc0 fdc0: f6b28d00 ffc1 0083 00db9000 ffc0 0015 fde0: e79dfe10 ffc0 001a0c68 ffc0 f6ff7000 ffc1 00d511e8 ffc0 fe00: 00db9000 ffc0 00d511e8 ffc0 e79dfe30 ffc0 001a1168 ffc0 fe20: f6ff7000 ffc1 e79dfe50 ffc0 001bcef0 ffc0 fe40: f6c8b080 ffc1 0015 e79dfe70 ffc0 001bcf94 ffc0 fe60: ed5d4190 ffc1 90a791c8 007f e79dfe80 ffc0 000ce47c ffc0 fe80: e79dfeb0 ffc0 00089800 ffc0 000c 79a5e4f0 0055 fea0: 90a791c8 007f dc5d82a0 007f 00085b54 ffc0 fec0: e79dfec0 ffc0 fee0: 8000 80808080 ff00: 80808080 0080 ff2f6172 fefefefe 0027 0004 ff20: 01010101 01010101 0030 0006 6974616f 6e2c656d ff40: 578b 90a79180 007f 756f8ed0 0055 ff60: 79a5e4f0 0055 79a5e4f0 0055 0002 ff80: 0002 79a5e550 0055 dc5d8410 007f ffa0: 79a5e530 0055 756f5df1 0055 dc5d82a0
4.2 kernel trace when hot unplug a mounted USB/SATA/MMC devices with ext2/ext3/ext4 file system
Hi Theodore, Andreas, Jan, Andrew and All, We are seeing kernel trace when we disconnect an USB/SATA/MMC devices that has its ext2/ext3/ext4 partition currently mounted. These traces are seen with kernel 4.2-rc5 on APM Arm64 X-Gene platforms. Similar issue also happens on an x86 machine (Lenovo T420s running Fedora Core 22 (Linux 4.1.x)) We also tested with xfs kernel and kernel complains with some error message but there is no trace: usb 1-1: USB disconnect, device number 3 XFS (sda1): Unmounting Filesystem XFS (sda1): metadata I/O error: block 0x1ddc12 (xlog_iodone) error 19 numblks 64 XFS (sda1): xfs_do_force_shutdown(0x2) called from line 1180 of file /projects/svdc/P4wsIPCSW/buildsw_shadowcat_2_03/shadowcat/linux/fs/xfs/xfs_log.c. Return address = 0xffc0003aa8d8 XFS (sda1): Log I/O Error Detected. Shutting down filesystem XFS (sda1): Unable to update superblock counters. Freespace may not be correct on next mount. XFS (sda1): xfs_log_force: error -5 returned. XFS (sda1): Please umount the filesystem and rectify the problem(s) Below are traces for each case. Do you aware of this issue and is there a fix for it? CASE 1: SATA with ext2 partition: EXT2-fs (sda1): previous I/O error to superblock detected Unable to handle kernel paging request at virtual address 1ff256000 pgd = ffc0e784b000 [1ff256000] *pgd=, *pud= Internal error: Oops: 9605 [#1] PREEMPT SMP Modules linked in: CPU: 4 PID: 1484 Comm: umount Not tainted 4.1.0-xgene_sw_2.03.05-beta_rc_pm #1 Hardware name: APM X-Gene Mustang board (DT) task: ffc1ed5d3840 ti: ffc0e79dc000 task.ti: ffc0e79dc000 PC is at __percpu_counter_add+0x2c/0x10c LR is at account_page_dirtied+0x78/0x12c pc : [ffc00043666c] lr : [ffc000147180] pstate: 81c5 sp : ffc0e79dfc40 x29: ffc0e79dfc40 x28: ffc0e79dc000 x27: ffc000927000 x26: 0027 x25: 011a x24: 0015 x23: 8000 x22: 0140 x21: ffc000d33000 x20: ffc1f6440fb8 x19: ffbec7b3e500 x18: x17: 007f8d95bfd0 x16: ffc0001dfad0 x15: 003b9aca x14: 0ffe x13: 0020 x12: 0101010101010101 x11: 0174 x10: 0006 x9 : ffc1fff1e35c x8 : 746564206b636f6c x7 : ffc000d33618 x6 : 0001ff256000 x5 : ffc0e79dfc40 x4 : ffc0e79dc000 x3 : x2 : 0020 x1 : 0001 x0 : 0001ff256000 Process umount (pid: 1484, stack limit = 0xffc0e79dc020) Stack: (0xffc0e79dfc40 to 0xffc0e79e) fc40: e79dfc70 ffc0 00147180 ffc0 c7b3e500 ffbe f6440f78 ffc1 fc60: e79dfc70 ffc0 0014716c ffc0 e79dfcb0 ffc0 001ccd7c ffc0 fc80: c7b3e500 ffbe f6b28f48 ffc1 f6b28f60 ffc1 e79dfca0 ffc0 fca0: f6b28f48 ffc1 e79dfd00 ffc0 001cdfd4 ffc0 fcc0: c7b3e500 ffbe ecf94400 ffc1 ee6022d8 ffc0 fce0: 8000 00226674 ffc0 e79dfd20 ffc0 fd00: e79dfd20 ffc0 0022ac84 ffc0 f6ff7000 ffc1 ecf94400 ffc1 fd20: e79dfd50 ffc0 0022ad0c ffc0 f677e380 ffc1 ecf94400 ffc1 fd40: f6ff7000 ffc1 ed5d3840 ffc1 e79dfd90 ffc0 001cb0c4 ffc0 fd60: f6ff7000 ffc1 f6ff70a8 ffc1 00946080 ffc0 001b5ff0 ffc0 fd80: f6ff7000 ffc1 e79dfdb0 ffc0 001a05e0 ffc0 fda0: f6ff7000 ffc1 0083 e79dfde0 ffc0 001a0958 ffc0 fdc0: f6b28d00 ffc1 0083 00db9000 ffc0 0015 fde0: e79dfe10 ffc0 001a0c68 ffc0 f6ff7000 ffc1 00d511e8 ffc0 fe00: 00db9000 ffc0 00d511e8 ffc0 e79dfe30 ffc0 001a1168 ffc0 fe20: f6ff7000 ffc1 e79dfe50 ffc0 001bcef0 ffc0 fe40: f6c8b080 ffc1 0015 e79dfe70 ffc0 001bcf94 ffc0 fe60: ed5d4190 ffc1 90a791c8 007f e79dfe80 ffc0 000ce47c ffc0 fe80: e79dfeb0 ffc0 00089800 ffc0 000c 79a5e4f0 0055 fea0: 90a791c8 007f dc5d82a0 007f 00085b54 ffc0 fec0: e79dfec0 ffc0 fee0: 8000 80808080 ff00: 80808080 0080 ff2f6172 fefefefe 0027 0004 ff20: 01010101 01010101 0030 0006 6974616f 6e2c656d ff40: 578b 90a79180 007f 756f8ed0 0055 ff60: 79a5e4f0 0055 79a5e4f0 0055 0002 ff80: 0002 79a5e550 0055 dc5d8410 007f ffa0: 79a5e530 0055 756f5df1 0055 dc5d82a0 007f ffc0: 756a2ae0 0055 dc5d8150 007f 90a791c8 007f 8000 ffe0: 79a5e530 0055 0027 Call trace: [ffc00043666c] __percpu_counter_add+0x2c/0x10c
