This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
trusty' to 'verification-done-trusty'.
If verification is not done by 5 working days from
** Also affects: linux (Ubuntu Precise)
Importance: Undecided
Status: New
** No longer affects: linux (Ubuntu Precise)
** Also affects: linux-lts-trusty (Ubuntu)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Precise)
Importance: Undecided
Status:
I've nominated Precise as well based on the description indicating a
recreate there.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1371591
Title:
file not initialized to 0s under some conditions on
** Branch linked: lp:ubuntu/trusty-proposed/linux-keystone
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1371591
Title:
file not initialized to 0s under some conditions on VMWare
To manage
** Branch linked: lp:ubuntu/precise-proposed/linux-lts-trusty
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1371591
Title:
file not initialized to 0s under some conditions on VMWare
To manage
Hi Chris,
This is Arvind Kumar from VMware. Recently the issue discussed in this
bug was brought into VMware's notice. We looked at the patch
(https://lkml.org/lkml/2014/9/23/509) which was done to address the
issue. Since the patch is done in mptsas driver, it addresses the issue
only on
Hi Chris,
can you revert original patch which blacklist VMware for no good reason, and
instead apply attached patch, or its equivalent? As explained above, bug
affects ALL disks that do not support WRITE_SAME when used with stackable block
devices, like LVM. Due to the bug Linux kernel stops
@petr-vmware, arvindkumar:
Thanks for looking into this!
I think your analysis makes more sense, because we'd expect the manually
zeroing to actually work instead of causing corruption. What kind of testing
and configurations have you done this on?
Can you submit this patch upstream and
** Tags added: patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1371591
Title:
file not initialized to 0s under some conditions on VMWare
To manage notifications about this bug go to:
This bug was fixed in the package linux - 3.16.0-20.27
---
linux (3.16.0-20.27) utopic; urgency=low
[ Tim Gardner ]
* [Config] CONFIG_CXL=m
* Release Tracking Bug
- LP: #1376354
[ Andi Kleen ]
* SAUCE: perf tools: Fix perf record as non root with kptr_restrict == 1
** Changed in: linux (Ubuntu)
Status: In Progress = Fix Committed
** Changed in: linux (Ubuntu Trusty)
Status: New = Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1371591
Patch here:
http://git.infradead.org/users/hch/scsi-queue.git/commit/4089b71cc820a426d601283c92fcd4ffeb5139c2
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1371591
Title:
file not initialized to 0s
https://lkml.org/lkml/2014/9/23/509
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1371591
Title:
file not initialized to 0s under some conditions on VMWare
To manage notifications about this bug
Thanks Chris.
I take it from the other thread that bubbling the setting up from the lower
layer to the dm-* layer won't be possible.
Do you know if this patch will fix it for ESXi as well as for the VMWare
desktop products? I don't have access to ESXi, but the issue was originally
reported to us
Bruce,
The following should get some of the info needed:
tail /sys/class/scsi_device/*/device/{vendor,model}
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1371591
Title:
file not initialized to 0s
This is what the customer reports. Ignoring the CD-ROM, this is slightly
different from what I see on my VMWare Fusion installation, which reports
VMware, (with a comma and a space). Presumably this is an insignificant
difference?
Bruce
tail /sys/class/scsi_device/*/device/{vendor,model}
==
Ok my experiment doing the following (and I know launchpad will mangle
my spacing...):
diff --git a/block/blk-lib.c b/block/blk-lib.c
index 9b5b561..03ad981 100644
--- a/block/blk-lib.c
+++ b/block/blk-lib.c
@@ -283,6 +283,7 @@ int __blkdev_issue_zeroout(struct block_device *bdev,
sector_t
As a workaround, you can use IDE/SATA disks instead of SCSI (default),
I'm not sure of performance implications, but the test cases passes.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1371591
Can you try this build and see if it fixes the issue? Please install it into
the guest VM:
http://people.canonical.com/~arges/lp1371591/
Thanks,
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1371591
I can confirm that this fixes the issue, both for the mongod repro and
for the standalone repro attached to this report.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1371591
Title:
file not
** Summary changed:
- FS Corruption with Ubuntu and VMWare
+ file not initialized to 0s under some conditions on VMWare
** Attachment added: reproducer
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1371591/+attachment/4208902/+files/repro.tgz
--
You received this bug notification
So are you sure 20GB is enough disk space for the VM? I tried in a KVM
VM (just to try the reproducer) and I get 'No space left on device'
errors from fallocate.
In addition can you post the machine information someone in this bug so
I can reproduce the exact setup on my end with vmware.
Also to
20 GB should be more than enough. It should run the repro binary several
times, using more disk space each time since it leaves the each run in
place when it goes on to the next, and then get a failure from fallocate
on the last one when the disk is filled up. I've attached a file showing
a
** Attachment added: sample repro script output
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1371591/+attachment/4208971/+files/repro.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
When creating the VM, did you use the default settings, or was the
hardware configuration changed at all? I.e. did you add extra
processors, or just use 1?
I'll look into my errors a bit more, getting VMWare Workstation setup;
has this been only reproduced in VMWare Fusion? Also are there
** Changed in: linux (Ubuntu)
Status: Incomplete = In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1371591
Title:
file not initialized to 0s under some conditions on VMWare
To
@bruce-lucas:
Ok! I can reproduce this issue in VMWare Workstation. I'll start investigating
more deeply.
In my KVM instance previously I did not reproduce the issue.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I accepted all the default settings when creating the VM (which for
Fusion was 20 GB disk, 1 GB memory, single processor).
On Fusion at least It is important to do the manual install: select
installation method / more options / create a custom VM, mount the CD,
set as boot device, bot up, go
** Information type changed from Public to Public Security
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1371591
Title:
file not initialized to 0s under some conditions on VMWare
To manage
Awesome, thanks.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1371591
Title:
file not initialized to 0s under some conditions on VMWare
To manage notifications about this bug go to:
By the way, a couple more pieces of information that may be relevant:
The problem is sensitive to the particular pattern of access to map0. If
you remove either of the two writes (at 0x0 and 0x7000) the problem
disappears, or if you change 0x7000 to a higher page it also disappears.
We also
** Tags added: kernel-da-key
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1371591
Title:
file not initialized to 0s under some conditions on VMWare
To manage notifications about this bug go to:
@bruce-lucas
OK I have reproduced this with the latest 3.17-rc kernel. So most likely this
is an upstream issue.
However I'll start testing previous versions to see if this is a regression
between 3.10,3.11; this will help us zero in on the code changes that may have
introduced this behavior.
The 'regression' is between 3.9 and 3.10-rc1. I'll bisect between these
tags to see where the issue is.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1371591
Title:
file not initialized to 0s under
FWIW, I also tested this on a similar KVM instance using a SCSI disk
device and installed Ubuntu using LVM, running the same test case does
not result in the failure; even though write_same is enabled for those
devices.
ubuntu@lp1371591:~$ lsblk
NAMEMAJ:MIN RM SIZE
The bisect resulted in the following:
dc019b21fb92d620a3b52ccecc135ac968a7c7ec is the first bad commit
commit dc019b21fb92d620a3b52ccecc135ac968a7c7ec
Author: Mike Snitzer snit...@redhat.com
Date: Fri May 10 14:37:16 2013 +0100
dm table: fix write same support
If
The bisect resulted in the following:
dc019b21fb92d620a3b52ccecc135ac968a7c7ec is the first bad commit
commit dc019b21fb92d620a3b52ccecc135ac968a7c7ec
Author: Mike Snitzer snit...@redhat.com
Date: Fri May 10 14:37:16 2013 +0100
dm table: fix write same support
If
As you mentioned in #10, blkdev_issue_zeroout (the function that prints
'WRITE SAME failed. Manually zeroing.'), still causes the test to show
failures even if we should be manually zeroing out the block device when
the hardware write_same fails. A test I could try is to short circuit
BLKZEROOUT
38 matches
Mail list logo
