Kernel crashed while Creating a second RAID volume on Ubuntu 16.04 OS.

[Chaitra P B]

Booted into Ubuntu16.04(4.4.0-21-generic) OS with inbox driver- v12.100.00.00,

Successfully discovered HBA and the devices connected to HBA.
>>Launched SAS3IRCU utility and created a RAID volume (RAID0/RAID1/RAID10). volume successfully created and listed from SAS3IRCU utility.
>>Tried to create a second RAID volume (RAID0/RAID1/RAID10) from SAS3IRCU utility.
Kernel crashed here while creating second volume.
>>tried with all possible combinations of RAID volumes.

Please find the attached kernel crash logs.

>>cat /proc/version_signature
Ubuntu 4.4.0-21.37-generic 4.4.6

HBA used : LSI SAS3(Fury)

Issue : Kernel gets crashed , when tried creating 2nd RAID volume.
Expected : One should be able to create MAX 2 RAID volumes at any point of time successfully , without any kernel crash.
---
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
CurrentDesktop: Unity
DistroRelease: Ubuntu 16.04
HibernationDevice: RESUME=UUID=7f36ec0c-c34b-4750-bd78-2c394cc513b2
InstallationDate: Installed on 2016-05-11 (1 days ago)
InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.3)
IwConfig:
 enp5s0f0 no wireless extensions.

 enp5s0f1 no wireless extensions.

 lo no wireless extensions.
MachineType: Supermicro X9DRH-7TF/7F/iTF/iF
Package: linux (not installed)
ProcFB: 0 VESA VGA
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-22-generic root=UUID=8f5b571b-235f-4881-8344-dfaa2bd9ed48 ro
ProcVersionSignature: Ubuntu 4.4.0-22.39-generic 4.4.8
PulseList:
 Error: command ['pacmd', 'list'] failed with exit code 1: XDG_RUNTIME_DIR (/run/user/1000) is not owned by us (uid 0), but by uid 1000! (This could e g happen if you try to connect to a non-root PulseAudio as a root user, over the native protocol. Don't do that.)
 No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
 linux-restricted-modules-4.4.0-22-generic N/A
 linux-backports-modules-4.4.0-22-generic N/A
 linux-firmware 1.157
RfKill:

Tags: xenial
Uname: Linux 4.4.0-22-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

_MarkForUpload: True
dmi.bios.date: 04/28/2014
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 3.0b
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: X9DRH-7TF/7F/iTF/iF
dmi.board.vendor: Supermicro
dmi.board.version: 1234567890
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: Supermicro
dmi.chassis.version: 1234567890
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr3.0b:bd04/28/2014:svnSupermicro:pnX9DRH-7TF/7F/iTF/iF:pvr1234567890:rvnSupermicro:rnX9DRH-7TF/7F/iTF/iF:rvr1234567890:cvnSupermicro:ct3:cvr1234567890:
dmi.product.name: X9DRH-7TF/7F/iTF/iF
dmi.product.version: 1234567890
dmi.sys.vendor: Supermicro
---
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
CurrentDesktop: Unity
DistroRelease: Ubuntu 16.04
HibernationDevice: RESUME=UUID=7f36ec0c-c34b-4750-bd78-2c394cc513b2
InstallationDate: Installed on 2016-05-11 (1 days ago)
InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.3)
IwConfig:
 enp5s0f0 no wireless extensions.

 enp5s0f1 no wireless extensions.

 lo no wireless extensions.
MachineType: Supermicro X9DRH-7TF/7F/iTF/iF
Package: linux (not installed)
ProcFB: 0 VESA VGA
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-22-generic root=UUID=8f5b571b-235f-4881-8344-dfaa2bd9ed48 ro
ProcVersionSignature: Ubuntu 4.4.0-22.39-generic 4.4.8
PulseList:
 Error: command ['pacmd', 'list'] failed with exit code 1: XDG_RUNTIME_DIR (/run/user/1000) is not owned by us (uid 0), but by uid 1000! (This could e g happen if you try to connect to a non-root PulseAudio as a root user, over the native protocol. Don't do that.)
 No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
 linux-restricted-modules-4.4.0-22-generic N/A
 linux-backports-modules-4.4.0-22-generic N/A
 linux-firmware 1.157
RfKill:

Tags: xenial
Uname: Linux 4.4.0-22-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

_MarkForUpload: True
dmi.bios.date: 04/28/2014
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 3.0b
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: X9DRH-7TF/7F/iTF/iF
dmi.board.vendor: Supermicro
dmi.board.version: 1234567890
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: Supermicro
dmi.chassis.version: 1234567890
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr3.0b:bd04/28/2014:svnSupermicro:pnX9DRH-7TF/7F/iTF/iF:pvr1234567890:rvnSupermicro:rnX9DRH-7TF/7F/iTF/iF:rvr1234567890:cvnSupermicro:ct3:cvr1234567890:
dmi.product.name: X9DRH-7TF/7F/iTF/iF
dmi.product.version: 1234567890
dmi.sys.vendor: Supermicro
---
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
CurrentDesktop: Unity
DistroRelease: Ubuntu 16.04
HibernationDevice: RESUME=UUID=7f36ec0c-c34b-4750-bd78-2c394cc513b2
InstallationDate: Installed on 2016-05-11 (1 days ago)
InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.3)
IwConfig:
 enp5s0f0 no wireless extensions.

 enp5s0f1 no wireless extensions.

 lo no wireless extensions.
MachineType: Supermicro X9DRH-7TF/7F/iTF/iF
Package: linux (not installed)
ProcFB: 0 VESA VGA
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-22-generic root=UUID=8f5b571b-235f-4881-8344-dfaa2bd9ed48 ro
ProcVersionSignature: Ubuntu 4.4.0-22.39-generic 4.4.8
PulseList:
 Error: command ['pacmd', 'list'] failed with exit code 1: XDG_RUNTIME_DIR (/run/user/1000) is not owned by us (uid 0), but by uid 1000! (This could e g happen if you try to connect to a non-root PulseAudio as a root user, over the native protocol. Don't do that.)
 No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
 linux-restricted-modules-4.4.0-22-generic N/A
 linux-backports-modules-4.4.0-22-generic N/A
 linux-firmware 1.157
RfKill:

Tags: xenial
Uname: Linux 4.4.0-22-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

_MarkForUpload: True
dmi.bios.date: 04/28/2014
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 3.0b
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: X9DRH-7TF/7F/iTF/iF
dmi.board.vendor: Supermicro
dmi.board.version: 1234567890
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: Supermicro
dmi.chassis.version: 1234567890
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr3.0b:bd04/28/2014:svnSupermicro:pnX9DRH-7TF/7F/iTF/iF:pvr1234567890:rvnSupermicro:rnX9DRH-7TF/7F/iTF/iF:rvr1234567890:cvnSupermicro:ct3:cvr1234567890:
dmi.product.name: X9DRH-7TF/7F/iTF/iF
dmi.product.version: 1234567890
dmi.sys.vendor: Supermicro

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1581326

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Chaitra P B (chaitra-basappa)]

apport information

[Joseph Salisbury (jsalisbury)]

Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.6 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-rc7-wily/

[Chaitra P B (chaitra-basappa)]

Joseph,
 Tested with latest upstream kernel : http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-yakkety/
issue not observed and hence looks like this bug is fixed in mainline kernel 'kernel-fixed-upstream'

[Joseph Salisbury (jsalisbury)]

That is good new that this is already fixed upstream. That means we can perform a "Reverse" bisect to identify the commit that fixes this.

Can you first test the latest upstream 4.4 kernel to see if the fix was also sent to -stable? It can be downloaded from:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.11-xenial/

[Chaitra P B (chaitra-basappa)]

Joseph,
 Issue is observed with the latest upstream 4.4 kernel.

[Chaitra P B (chaitra-basappa)]

Joseph,
 Could you please let us know which patch/commit of upstream has fixed this issue??
It will be helpful if we get this information at the earliest , as we are providing out of box driver support for Ubuntu 16.04.

Thanks,
 Chaitra

[Brad Figg (brad-figg)]

This change was made by a bot.

[Chaitra P B (chaitra-basappa)]

Hi Brad,
 I had requested Joseph an information regarding which patch/commit of upstream has fixed this issue??

So not sure what should be the status of BZ, it was "TRIAGED" earlier Since i didn't find any option to set status as request_info.., moved status to new..Hoping that i may get requested information.
Please let me know on how to proceed with this BZ to know the status on requested information.

[Chaitra P B (chaitra-basappa)]

Joseph,
 Could you please share us the source for kernel- http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-yakkety/

As we reported earlier, issue was not happening with this kernel whereas issue hits with upstream kernel-4.6.2 and hence we want to know the diff of these two kernels.

[Joseph Salisbury (jsalisbury)]

Chaitra,

That source is in the current mainline tree:
git://kernel.ubuntu.com/ubuntu/linux.git
or
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/

Can you test the latest 4.4 stable kernel once more:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.14-xenial/

If the bug still exists in the 4.4.14 kernel, we would need to perform a reverse bisect to identify the fix.

[Chaitra P B (chaitra-basappa)]

Joseph,
 Issue still exists in the 4.4.14 kernel: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.14-xenial/

Please help us to identify the fix, attaching the logs og 4.4.14 kernel crash.

[Joseph Salisbury (jsalisbury)]

To perform a reverse bisect, we need to identify the last bad kernel version and the first good one. We know that 4.4.14 is bad and 4.6 final is good.

Can you next test the upstream 4.5. kernel? It can be downloaded from:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.5-wily/

If it is also good, we should test some of the release candidates. If it still bad, we should test some of the 4.6 release candidates. All of those kernels are also available from:
http://kernel.ubuntu.com/~kernel-ppa/mainline/

[John Culp (txbeerknurd)]

Has there been any update to identify where it broke and where it is fixed? What was the change?

[Chaitra P B (chaitra-basappa)]

Hi John,
 Root caused & identified the issue in the kernel, issue exits in the block layer. Also posted a patch which fix this issue to the upstream community.

Here is the URL of the posted patch,
https://marc.info/?l=linux-block&m=147731657127810&w=2

[Joseph Salisbury (jsalisbury)]

I see a V2 of the patch has been posted today:
https://lkml.org/lkml/2016/10/25/326

I'll build a test kernel and post it here when the finalized patch is available.

[Chaitra P B (chaitra-basappa)]

Joseph/John,
 The above mentioned patches(https://marc.info/?l=linux-block&m=147731657127810&w=2 and https://lkml.org/lkml/2016/10/25/326) are posted to upstream by us only.

So please consider V2 patch (https://lkml.org/lkml/2016/10/25/326) and let us know.

[Joseph Salisbury (jsalisbury)]

I can build a test kernel with the V2 version of the patch.

Has there been any response from upstream on the patch? It doesn't look like it landed in mainline as of yet.

[Joseph Salisbury (jsalisbury)]

I built a Xenial test kernel with the V2 patch. It can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1581326/

Can you test this kernel and see if it resolves this bug?

[Chaitra P B (chaitra-basappa)]

Joseph,
 Tested the above test kernel, issue is not observed.So the V2 patch has fixed the issue.

[Phong Nguyen (phong-pln)]

Hi Joseph,
I would like to test this patch this on IBM Power8 system
Can you build a test kernel for ppc64le?

Thanks

[Joseph Salisbury (jsalisbury)]

I compiled a test kernel for ppc66el. It is available from:
http://kernel.ubuntu.com/~jsalisbury/lp1581326/ppc64el

[Phong Nguyen (phong-pln)]

Hi Joseph,
This test kernel is also working for me.
I don't see kernel crash when creating 2 RAID volumes consecutively on a single boot.

Thanks

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2016-12-08 11:40 EDT-------
cde00 (<email address hidden>) added native attachment /tmp/AIXOS05880778/Ubuntu16.04_4.4.14_kernel_log.txt on 2016-12-08 10:02:22
cde00 (<email address hidden>) added native attachment /tmp/AIXOS05880778/Lsusb.txt on 2016-12-08 10:02:22
cde00 (<email address hidden>) added native attachment /tmp/AIXOS05880778/JournalErrors.txt on 2016-12-08 10:02:22
cde00 (<email address hidden>) added native attachment /tmp/AIXOS05880778/ubuntu_kernal_crash_raidvolume.dat on 2016-12-08 10:02:22
cde00 (<email address hidden>) added native attachment /tmp/AIXOS05880778/CurrentDmesg.txt on 2016-12-08 10:02:22
cde00 (<email address hidden>) added native attachment /tmp/AIXOS05880778/ProcModules.txt on 2016-12-08 10:02:22
cde00 (<email address hidden>) added native attachment /tmp/AIXOS05880778/ProcInterrupts.txt on 2016-12-08 10:02:22
cde00 (<email address hidden>) added native attachment /tmp/AIXOS05880778/AlsaInfo.txt on 2016-12-08 10:02:22
cde00 (<email address hidden>) added native attachment /tmp/AIXOS05880778/WifiSyslog.txt on 2016-12-08 10:02:22
cde00 (<email address hidden>) added native attachment /tmp/AIXOS05880778/UdevDb.txt on 2016-12-08 10:02:22
cde00 (<email address hidden>) added native attachment /tmp/AIXOS05880778/ProcCpuinfo.txt on 2016-12-08 10:02:22
cde00 (<email address hidden>) added native attachment /tmp/AIXOS05880778/CRDA.txt on 2016-12-08 10:02:22
cde00 (<email address hidden>) added native attachment /tmp/AIXOS05880778/Lspci.txt on 2016-12-08 10:02:22
cde00 (<email address hidden>) added native attachment /tmp/AIXOS05880778/ProcEnviron.txt on 2016-12-08 10:02:22

[Joseph Salisbury (jsalisbury)]

Does this bug also happen with Yakkety(4.8 based) and Zesty(mainline based)? I wanted to see if I should SRU the patch to those releases as well?

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[Joseph Salisbury (jsalisbury)]

Has there been any additional activity upstream on the V2 patch? The patch has not landed in mainline as of yet and I have not seen an update on the upstream thread.

Is this patch needed in Yakkety and Xenail or just Xenial? Is it needed in releases prior to Xenial?

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2017-01-23 09:11 EDT-------
The problem exists in 14.04, and as far as I can tell is not fixed upstream. So, this needs to be submitted upstream post-haste and should be considered for maintenance release of 14.04.

[Joseph Salisbury (jsalisbury)]

@Chaitra, do you have an update on the status of this patch upstream? If not, I can contact the patch author, Sreekanth Reddy, directly.

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[Chaitra P B (chaitra-basappa)]

Joseph,
 Patch is not accepted by upstream and below is the comment from one of the reviewer,

There seems to be problem with this patch. bdi_unregister() is also called by blk_cleanup_queue(), and both that and del_gendisk() may be called by cleanup_mapped_device(). This results in a panic when bdi_unregister() is called for the second time.

[bugproxy (bugproxy)]

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Has there been any additional activity upstream on the V2 patch? The patch has not landed in mainline as of yet and I have not seen an update on the upstream thread.

Is this patch needed in Yakkety and Xenail or just Xenial? Is it needed in releases prior to Xenial?

------- Comment From <email address hidden> 2017-01-23 09:11 EDT-------
The problem exists in 14.04, and as far as I can tell is not fixed upstream. So, this needs to be submitted upstream post-haste and should be considered for maintenance release of 14.04.
@Chaitra, do you have an update on the status of this patch upstream? If not, I can contact the patch author, Sreekanth Reddy, directly.
Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge
Joseph,
Patch is not accepted by upstream and below is the comment from one of the reviewer,

There seems to be problem with this patch. bdi_unregister() is also called by blk_cleanup_queue(), and both that and del_gendisk() may be called by cleanup_mapped_device(). This results in a panic when bdi_unregister() is called for the second time.

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Has there been any additional activity upstream on the V2 patch? The patch has not landed in mainline as of yet and I have not seen an update on the upstream thread.

Is this patch needed in Yakkety and Xenail or just Xenial? Is it needed in releases prior to Xenial?

------- Comment From <email address hidden> 2017-01-23 09:11 EDT-------
The problem exists in 14.04, and as far as I can tell is not fixed upstream. So, this needs to be submitted upstream post-haste and should be considered for maintenance release of 14.04.
@Chaitra, do you have an update on the status of this patch upstream? If not, I can contact the patch author, Sreekanth Reddy, directly.
Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge
Joseph,
Patch is not accepted by upstream and below is the comment from one of the reviewer,

There seems to be problem with this patch. bdi_unregister() is also called by blk_cleanup_queue(), and both that and del_gendisk() may be called by cleanup_mapped_device(). This results in a panic when bdi_unregister() is called for the second time.

------- Comment From <email address hidden> 2017-01-24 07:51 EDT-------
That was a problem with the first version of the patch. The second version does not exhibit that problem. What is the status of the second version of the patch?

------- Comment From <email address hidden> 2017-01-24 07:59 EDT-------
I have found the copy of the email and thread and replied, just to be certain. I thought my approval was not needed and that the patch was already on or pending someone's "next" branch. But if not, I have replied.

[bugproxy (bugproxy)]

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Has there been any additional activity upstream on the V2 patch? The patch has not landed in mainline as of yet and I have not seen an update on the upstream thread.

Is this patch needed in Yakkety and Xenail or just Xenial? Is it needed in releases prior to Xenial?

------- Comment From <email address hidden> 2017-01-23 09:11 EDT-------
The problem exists in 14.04, and as far as I can tell is not fixed upstream. So, this needs to be submitted upstream post-haste and should be considered for maintenance release of 14.04.
@Chaitra, do you have an update on the status of this patch upstream? If not, I can contact the patch author, Sreekanth Reddy, directly.
Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge
Joseph,
Patch is not accepted by upstream and below is the comment from one of the reviewer,

There seems to be problem with this patch. bdi_unregister() is also called by blk_cleanup_queue(), and both that and del_gendisk() may be called by cleanup_mapped_device(). This results in a panic when bdi_unregister() is called for the second time.

------- Comment From <email address hidden> 2017-01-24 07:51 EDT-------
That was a problem with the first version of the patch. The second version does not exhibit that problem. What is the status of the second version of the patch?

------- Comment From <email address hidden> 2017-01-24 07:59 EDT-------
I have found the copy of the email and thread and replied, just to be certain. I thought my approval was not needed and that the patch was already on or pending someone's "next" branch. But if not, I have replied.
Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Has there been any additional activity upstream on the V2 patch? The patch has not landed in mainline as of yet and I have not seen an update on the upstream thread.

Is this patch needed in Yakkety and Xenail or just Xenial? Is it needed in releases prior to Xenial?

The problem exists in 14.04, and as far as I can tell is not fixed upstream. So, this needs to be submitted upstream post-haste and should be considered for maintenance release of 14.04.
@Chaitra, do you have an update on the status of this patch upstream? If not, I can contact the patch author, Sreekanth Reddy, directly.
Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge
Joseph,
Patch is not accepted by upstream and below is the comment from one of the reviewer,

There seems to be problem with this patch. bdi_unregister() is also called by blk_cleanup_queue(), and both that and del_gendisk() may be called by cleanup_mapped_device(). This results in a panic when bdi_unregister() is called for the second time.

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

Defa...

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2017-06-07 09:35 EDT-------
(In reply to comment #106)
>
> Does this bug also happen with Yakkety(4.8 based) and Zesty(mainline based)?
> I wanted to see if I should SRU the patch to those releases as well?

We have seen two instances of this problem happening on Zesty this week. Both running 4.10.0-21-generic #23-Ubuntu kernels.

[Joseph Salisbury (jsalisbury)]

Has there been any additional activity on the patch upstream?

[Andy Whitcroft (apw)]

This bug was nominated against a series that is no longer supported, ie yakkety. The bug task representing the yakkety nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2017-10-07 23:22 EDT-------
There was never a patch provided here, this problem does not exist in current/newer Ubuntu releases. Closing.