Re: [BISECTED][REGRESSION] Hang while booting EeePC 900

On 2 April 2018 at 21:29, Tejun Heo wrote: > Hello, Sitsofe. > > Can you see whether the following patch makes any difference? > > Thanks. > > diff --git a/block/blk-timeout.c b/block/blk-timeout.c > index a05e367..f0e6e41 100644 > --- a/block/blk-timeout.c > +++

Re: [BISECTED][REGRESSION] Hang while booting EeePC 900

On 2 April 2018 at 21:29, Tejun Heo wrote: > Hello, Sitsofe. > > Can you see whether the following patch makes any difference? > > Thanks. > > diff --git a/block/blk-timeout.c b/block/blk-timeout.c > index a05e367..f0e6e41 100644 > --- a/block/blk-timeout.c > +++ b/block/blk-timeout.c > @@ -165,7

Re: [BISECTED][REGRESSION] Hang while booting EeePC 900

Hi Tejun, On 2 April 2018 at 21:29, Tejun Heo wrote: > > Can you see whether the following patch makes any difference? > > Thanks. > > diff --git a/block/blk-timeout.c b/block/blk-timeout.c > index a05e367..f0e6e41 100644 > --- a/block/blk-timeout.c > +++ b/block/blk-timeout.c >

Re: [BISECTED][REGRESSION] Hang while booting EeePC 900

Hi Tejun, On 2 April 2018 at 21:29, Tejun Heo wrote: > > Can you see whether the following patch makes any difference? > > Thanks. > > diff --git a/block/blk-timeout.c b/block/blk-timeout.c > index a05e367..f0e6e41 100644 > --- a/block/blk-timeout.c > +++ b/block/blk-timeout.c > @@ -165,7 +165,7

Re: [BISECTED][REGRESSION] Hang while booting EeePC 900

On 2 April 2018 at 15:33, Jens Axboe <ax...@kernel.dk> wrote: > On 4/1/18 8:35 AM, Sitsofe Wheeler wrote: >> >> While trying to boot an EeePC 900 on the latest git mainline kernel a >> hang is encountered while systemd is starting services but this did >> not happe

Re: [BISECTED][REGRESSION] Hang while booting EeePC 900

On 2 April 2018 at 15:33, Jens Axboe wrote: > On 4/1/18 8:35 AM, Sitsofe Wheeler wrote: >> >> While trying to boot an EeePC 900 on the latest git mainline kernel a >> hang is encountered while systemd is starting services but this did >> not happen with 4.15. A

[BISECTED][REGRESSION] Hang while booting EeePC 900

Hi, While trying to boot an EeePC 900 on the latest git mainline kernel a hang is encountered while systemd is starting services but this did not happen with 4.15. A bisection narrowed it down to the commit 358f70da49d77c43f2ca11b5da584213b2add29c ("blk-mq: make blk_abort_request() trigger

[BISECTED][REGRESSION] Hang while booting EeePC 900

Hi, While trying to boot an EeePC 900 on the latest git mainline kernel a hang is encountered while systemd is starting services but this did not happen with 4.15. A bisection narrowed it down to the commit 358f70da49d77c43f2ca11b5da584213b2add29c ("blk-mq: make blk_abort_request() trigger

Re: Warning from free_init_pages with large initrd

On 27 September 2016 at 22:21, Sitsofe Wheeler <sits...@gmail.com> wrote: > On 27 September 2016 at 19:36, H. Peter Anvin <h...@zytor.com> wrote: >> On September 27, 2016 3:20:06 AM PDT, Sitsofe Wheeler <sits...@gmail.com> >> wrote: >>>(See http://w

Re: Warning from free_init_pages with large initrd

On 27 September 2016 at 22:21, Sitsofe Wheeler wrote: > On 27 September 2016 at 19:36, H. Peter Anvin wrote: >> On September 27, 2016 3:20:06 AM PDT, Sitsofe Wheeler >> wrote: >>>(See http://www.gossamer-threads.com/lists/linux/kernel/2534175 for >>>the hist

Re: kernel BUG at block/bio.c:1785 while trying to issue a discard to LVM on RAID1 md

On 5 October 2016 at 22:39, Shaohua Li <s...@kernel.org> wrote: > On Wed, Oct 05, 2016 at 10:31:11PM +0100, Sitsofe Wheeler wrote: >> On 3 October 2016 at 17:47, Sitsofe Wheeler <sits...@gmail.com> wrote: >> > >> > While trying to do a discard (via blkdiscard

Re: kernel BUG at block/bio.c:1785 while trying to issue a discard to LVM on RAID1 md

On 5 October 2016 at 22:39, Shaohua Li wrote: > On Wed, Oct 05, 2016 at 10:31:11PM +0100, Sitsofe Wheeler wrote: >> On 3 October 2016 at 17:47, Sitsofe Wheeler wrote: >> > >> > While trying to do a discard (via blkdiscard --length 1048576 >> > /dev/) to an

Re: kernel BUG at block/bio.c:1785 while trying to issue a discard to LVM on RAID1 md

On 3 October 2016 at 17:47, Sitsofe Wheeler <sits...@gmail.com> wrote: > > While trying to do a discard (via blkdiscard --length 1048576 > /dev/) to an LVM device atop a two disk md RAID1 the > following oops was generated: > > [ 103.306243] md: resync of RAID array m

Re: kernel BUG at block/bio.c:1785 while trying to issue a discard to LVM on RAID1 md

On 3 October 2016 at 17:47, Sitsofe Wheeler wrote: > > While trying to do a discard (via blkdiscard --length 1048576 > /dev/) to an LVM device atop a two disk md RAID1 the > following oops was generated: > > [ 103.306243] md: resync of RAID array md127 > [ 103.306246] md:

Re: BUG and Oops while trying to issue a discard to LVM on RAID1 md

On 5 October 2016 at 16:04, Sitsofe Wheeler <sits...@gmail.com> wrote: > On 4 October 2016 at 07:20, Sitsofe Wheeler <sits...@gmail.com> wrote: >> On 4 October 2016 at 07:17, Sitsofe Wheeler <sits...@gmail.com> wrote: >>> While trying to do a discard insid

Re: BUG and Oops while trying to issue a discard to LVM on RAID1 md

On 5 October 2016 at 16:04, Sitsofe Wheeler wrote: > On 4 October 2016 at 07:20, Sitsofe Wheeler wrote: >> On 4 October 2016 at 07:17, Sitsofe Wheeler wrote: >>> While trying to do a discard inside an ESXi 6 VM to an LVM device atop >>> an md RAID1 device composed

Re: BUG and Oops while trying to issue a discard to LVM on RAID1 md

On 4 October 2016 at 07:20, Sitsofe Wheeler <sits...@gmail.com> wrote: > On 4 October 2016 at 07:17, Sitsofe Wheeler <sits...@gmail.com> wrote: >> While trying to do a discard inside an ESXi 6 VM to an LVM device atop >> an md RAID1 device composed of two SATA S

Re: BUG and Oops while trying to issue a discard to LVM on RAID1 md

On 4 October 2016 at 07:20, Sitsofe Wheeler wrote: > On 4 October 2016 at 07:17, Sitsofe Wheeler wrote: >> While trying to do a discard inside an ESXi 6 VM to an LVM device atop >> an md RAID1 device composed of two SATA SSDs passed up as a raw disk >> mappings throug

Re: BUG and Oops while trying to issue a discard to LVM on RAID1 md

On 4 October 2016 at 07:17, Sitsofe Wheeler <sits...@gmail.com> wrote: > While trying to do a discard inside an ESXi 6 VM to an LVM device atop > an md RAID1 device composed of two SATA SSDs passed up as a raw disk > mappings through a PVSCSI controller, this BUG followed by an

Re: BUG and Oops while trying to issue a discard to LVM on RAID1 md

On 4 October 2016 at 07:17, Sitsofe Wheeler wrote: > While trying to do a discard inside an ESXi 6 VM to an LVM device atop > an md RAID1 device composed of two SATA SSDs passed up as a raw disk > mappings through a PVSCSI controller, this BUG followed by an Oops was > hit: >

BUG and Oops while trying to issue a discard to LVM on RAID1 md

While trying to do a discard inside an ESXi 6 VM to an LVM device atop an md RAID1 device composed of two SATA SSDs passed up as a raw disk mappings through a PVSCSI controller, this BUG followed by an Oops was hit: [ 86.902888] [ cut here ] [ 86.904600] kernel BUG at

BUG and Oops while trying to issue a discard to LVM on RAID1 md

While trying to do a discard inside an ESXi 6 VM to an LVM device atop an md RAID1 device composed of two SATA SSDs passed up as a raw disk mappings through a PVSCSI controller, this BUG followed by an Oops was hit: [ 86.902888] [ cut here ] [ 86.904600] kernel BUG at

kernel BUG at block/bio.c:1785 while trying to issue a discard to LVM on RAID1 md

Hi, While trying to do a discard (via blkdiscard --length 1048576 /dev/) to an LVM device atop a two disk md RAID1 the following oops was generated: [ 103.306243] md: resync of RAID array md127 [ 103.306246] md: minimum _guaranteed_ speed: 1000 KB/sec/disk. [ 103.306248] md: using maximum

kernel BUG at block/bio.c:1785 while trying to issue a discard to LVM on RAID1 md

Hi, While trying to do a discard (via blkdiscard --length 1048576 /dev/) to an LVM device atop a two disk md RAID1 the following oops was generated: [ 103.306243] md: resync of RAID array md127 [ 103.306246] md: minimum _guaranteed_ speed: 1000 KB/sec/disk. [ 103.306248] md: using maximum

Re: Warning from free_init_pages with large initrd

On 27 September 2016 at 19:36, H. Peter Anvin <h...@zytor.com> wrote: > On September 27, 2016 3:20:06 AM PDT, Sitsofe Wheeler <sits...@gmail.com> > wrote: >>(See http://www.gossamer-threads.com/lists/linux/kernel/2534175 for >>the history of this thread ) >> &g

Re: Warning from free_init_pages with large initrd

On 27 September 2016 at 19:36, H. Peter Anvin wrote: > On September 27, 2016 3:20:06 AM PDT, Sitsofe Wheeler > wrote: >>(See http://www.gossamer-threads.com/lists/linux/kernel/2534175 for >>the history of this thread ) >> >>On 26 September 2016 a

Re: Warning from free_init_pages with large initrd

(See http://www.gossamer-threads.com/lists/linux/kernel/2534175 for the history of this thread ) On 26 September 2016 at 20:00, Randy Dunlap wrote: > > but the warning in free_init_pages() is about alignment, not size... > Maybe the concatenation is bad? What would l have

Re: Warning from free_init_pages with large initrd

(See http://www.gossamer-threads.com/lists/linux/kernel/2534175 for the history of this thread ) On 26 September 2016 at 20:00, Randy Dunlap wrote: > > but the warning in free_init_pages() is about alignment, not size... > Maybe the concatenation is bad? What would l have to pull apart to be

Re: Warning from free_init_pages with large initrd

On 26 September 2016 at 07:47, H. Peter Anvin <h...@zytor.com> wrote: > On September 25, 2016 11:22:04 PM PDT, Sitsofe Wheeler <sits...@gmail.com> > wrote: >>On 26 September 2016 at 03:14, H. Peter Anvin <h...@zytor.com> wrote: >>> On 09/24/16 08:32, Sitsof

Re: Warning from free_init_pages with large initrd

On 26 September 2016 at 07:47, H. Peter Anvin wrote: > On September 25, 2016 11:22:04 PM PDT, Sitsofe Wheeler > wrote: >>On 26 September 2016 at 03:14, H. Peter Anvin wrote: >>> On 09/24/16 08:32, Sitsofe Wheeler wrote: >>>> >>>> While tryin

Re: Warning from free_init_pages with large initrd

On 26 September 2016 at 03:14, H. Peter Anvin <h...@zytor.com> wrote: > On 09/24/16 08:32, Sitsofe Wheeler wrote: >> >> While trying to PXE boot a Fedora LiveISO on VMware ESXi the kernel >> throws the following warning: >> > [...] >> >> The initrd

Re: Warning from free_init_pages with large initrd

On 26 September 2016 at 03:14, H. Peter Anvin wrote: > On 09/24/16 08:32, Sitsofe Wheeler wrote: >> >> While trying to PXE boot a Fedora LiveISO on VMware ESXi the kernel >> throws the following warning: >> > [...] >> >> The initrd is big because it ho

Warning from free_init_pages with large initrd

Hi, While trying to PXE boot a Fedora LiveISO on VMware ESXi the kernel throws the following warning: [0.955216] Unpacking initramfs... [5.391977] [ cut here ] [5.391986] WARNING: CPU: 0 PID: 1 at arch/x86/mm/init.c:671 free_init_pages+0x94/0xa0 [

Warning from free_init_pages with large initrd

Hi, While trying to PXE boot a Fedora LiveISO on VMware ESXi the kernel throws the following warning: [0.955216] Unpacking initramfs... [5.391977] [ cut here ] [5.391986] WARNING: CPU: 0 PID: 1 at arch/x86/mm/init.c:671 free_init_pages+0x94/0xa0 [

Re: BLKZEROOUT not zeroing md dev on VMDK

On Wed, Jun 15, 2016 at 06:17:37PM +, Arvind Kumar wrote: > It is possibly some race. We saw a WRITE SAME related issue in past > for which Petr sent out a patch but looks like the patch didn't make > it. :( > > https://groups.google.com/forum/#!topic/linux.kernel/1WGDSlyY0y0 Indeed - the

Re: BLKZEROOUT not zeroing md dev on VMDK

On Wed, Jun 15, 2016 at 06:17:37PM +, Arvind Kumar wrote: > It is possibly some race. We saw a WRITE SAME related issue in past > for which Petr sent out a patch but looks like the patch didn't make > it. :( > > https://groups.google.com/forum/#!topic/linux.kernel/1WGDSlyY0y0 Indeed - the

Re: [PATCH V2] block: correctly fallback for zeroout

On Tue, Jun 07, 2016 at 07:58:25AM -0700, Shaohua Li wrote: > > I didn't follow. io_err is only and always set when ret == 0. io_err is > meanless if ret != 0, because that means the disk doesn't support discard and > we don't dispatch discard IO. why should we initialized io_err to 0? My mistake

Re: [PATCH V2] block: correctly fallback for zeroout

On Tue, Jun 07, 2016 at 07:58:25AM -0700, Shaohua Li wrote: > > I didn't follow. io_err is only and always set when ret == 0. io_err is > meanless if ret != 0, because that means the disk doesn't support discard and > we don't dispatch discard IO. why should we initialized io_err to 0? My mistake

Re: [PATCH V2] block: correctly fallback for zeroout

On Tue, Jun 14, 2016 at 10:14:50PM -0400, Martin K. Petersen wrote: > > "Christoph" == Christoph Hellwig writes: > > Christoph> And I'd much prefer to get this right now. It's not like > Christoph> this is recently introduced behavior. > > Unfortunately there are quite

Re: [PATCH V2] block: correctly fallback for zeroout

On Tue, Jun 14, 2016 at 10:14:50PM -0400, Martin K. Petersen wrote: > > "Christoph" == Christoph Hellwig writes: > > Christoph> And I'd much prefer to get this right now. It's not like > Christoph> this is recently introduced behavior. > > Unfortunately there are quite a few callers of

Re: [PATCH V2] block: correctly fallback for zeroout

t; disk data not changed. zeroout should have guaranteed zero-fill > behavior. > > https://bugzilla.kernel.org/show_bug.cgi?id=118581 > > V2: move the return value policy to blkdev_issue_discard and > delete the policy for blkdev_issue_write_same (Martin) > > Cc: Sitsofe Wheeler &l

Re: [PATCH V2] block: correctly fallback for zeroout

t; disk data not changed. zeroout should have guaranteed zero-fill > behavior. > > https://bugzilla.kernel.org/show_bug.cgi?id=118581 > > V2: move the return value policy to blkdev_issue_discard and > delete the policy for blkdev_issue_write_same (Martin) > > Cc: Sitsofe Wheeler

Re: BLKZEROOUT not zeroing md dev on VMDK

On 27 May 2016 at 10:30, Tom Yan wrote: > There seems to be some sort of race condition between > blkdev_issue_zeroout() and the scsi disk driver (disabling write same > after an illegal request). On my UAS drive, sometimes `blkdiscard -z > /dev/sdX` will return right away,

Re: BLKZEROOUT not zeroing md dev on VMDK

On 27 May 2016 at 10:30, Tom Yan wrote: > There seems to be some sort of race condition between > blkdev_issue_zeroout() and the scsi disk driver (disabling write same > after an illegal request). On my UAS drive, sometimes `blkdiscard -z > /dev/sdX` will return right away, even though if I then

Re: [PATCH] block: correctly fallback for zeroout

On Sat, May 28, 2016 at 08:55:43AM +, Sitsofe Wheeler wrote: > On Thu, May 26, 2016 at 11:08:14AM -0700, Shaohua Li wrote: > > blkdev_issue_zeroout try discard/writesame first, if they fail, zeroout > > fallback to regular write. The problem is discard/writesame doesn't &

Re: [PATCH] block: correctly fallback for zeroout

On Sat, May 28, 2016 at 08:55:43AM +, Sitsofe Wheeler wrote: > On Thu, May 26, 2016 at 11:08:14AM -0700, Shaohua Li wrote: > > blkdev_issue_zeroout try discard/writesame first, if they fail, zeroout > > fallback to regular write. The problem is discard/writesame doesn't &

Re: BLKZEROOUT not zeroing md dev on VMDK

On 27 May 2016 at 05:18, Darrick J. Wong wrote: > > It's possible that the pvscsi device advertised WRITE SAME, but if the device > sends back ILLEGAL REQUEST then the SCSI disk driver will set > write_same_max_bytes=0. Subsequent BLKZEROOUT attempts will then issue

Re: BLKZEROOUT not zeroing md dev on VMDK

On 27 May 2016 at 05:18, Darrick J. Wong wrote: > > It's possible that the pvscsi device advertised WRITE SAME, but if the device > sends back ILLEGAL REQUEST then the SCSI disk driver will set > write_same_max_bytes=0. Subsequent BLKZEROOUT attempts will then issue writes > of zeroes to the

BLKZEROOUT not zeroing md dev on VMDK

Hi, With Ubuntu's 4.4.0-22-generic kernel and a Fedora 23 4.6.0-1.vanilla.knurd.1.fc23.x86_64 kernel I've found that the BLKZEROOUT syscall can malfunction and not zero data. When BLKZEROOUT is issued to an MD device atop a PVSCSI controller supplied VMDK from ESXi 6.0 the call returns

BLKZEROOUT not zeroing md dev on VMDK

Hi, With Ubuntu's 4.4.0-22-generic kernel and a Fedora 23 4.6.0-1.vanilla.knurd.1.fc23.x86_64 kernel I've found that the BLKZEROOUT syscall can malfunction and not zero data. When BLKZEROOUT is issued to an MD device atop a PVSCSI controller supplied VMDK from ESXi 6.0 the call returns

Re: Small writes being split with fdatasync based on non-aligned partition ending

CC'ing Jens Axboe. On 11 February 2016 at 09:54, Jens Rosenboom wrote: > 2016-02-11 4:48 GMT+01:00 Sitsofe Wheeler : >> Trying to cc the GNU parted and linux-block mailing lists. >> >> On 9 February 2016 at 13:02, Jens Rosenboom wrote: >>> While trying to repro

Re: Small writes being split with fdatasync based on non-aligned partition ending

CC'ing Jens Axboe. On 11 February 2016 at 09:54, Jens Rosenboom <j.rosenb...@x-ion.de> wrote: > 2016-02-11 4:48 GMT+01:00 Sitsofe Wheeler <sits...@gmail.com>: >> Trying to cc the GNU parted and linux-block mailing lists. >> >> On 9 February 2016 at 13:02, Jen

Re: Small writes being split with fdatasync based on non-aligned partition ending

Trying to cc the GNU parted and linux-block mailing lists. On 9 February 2016 at 13:02, Jens Rosenboom wrote: > While trying to reproduce some performance issues I have been seeing > with Ceph, I have come across a strange behaviour which is seemingly > affected only by the end point (and

Re: Small writes being split with fdatasync based on non-aligned partition ending

Trying to cc the GNU parted and linux-block mailing lists. On 9 February 2016 at 13:02, Jens Rosenboom wrote: > While trying to reproduce some performance issues I have been seeing > with Ceph, I have come across a strange behaviour which is seemingly > affected only by the

Re: [PATCH] scsi:storvsc enable reading from VPD pages on SPC-2

On Wed, Dec 10, 2014 at 11:30:30PM +, KY Srinivasan wrote: > > > > > > > + {"Msft", "Virtual Disk", "1.0", BLIST_TRY_VPD_PAGES}, > > > > > > Is that version field meaningful or is it safe for us to inquire about > > > VPD pages without problems on older versions? > > > > This version is used

Re: [PATCH] scsi:storvsc enable reading from VPD pages on SPC-2

On Wed, Dec 10, 2014 at 11:30:30PM +, KY Srinivasan wrote: + {Msft, Virtual Disk, 1.0, BLIST_TRY_VPD_PAGES}, Is that version field meaningful or is it safe for us to inquire about VPD pages without problems on older versions? This version is used in all current Hyper-V

Re: [PATCH] scsi:storvsc enable reading from VPD pages on SPC-2

On Wed, Dec 10, 2014 at 12:38:25AM -0800, Long Li wrote: > MSFT targets currently claim SPC-2 compliance while they implement > post SPC-2 features. With this patch we can correctly handle > WRITE_SAME_16 issues. > > This patch fixes an issue where the flag is setup too late in drive >

Re: [PATCH 3/3] Drivers: hv: hv_balloon: Don't post pressure status from interrupt context

On Mon, Dec 08, 2014 at 06:04:35AM +, KY Srinivasan wrote: > > Greg has not committed these patches yet. One of the patches changes the > balloon floor. > This means that the guest will not be ballooned down below the floor. Is this > what you are > seeing? In our testing we did not see

Re: [PATCH 3/3] Drivers: hv: hv_balloon: Don't post pressure status from interrupt context

On Mon, Dec 08, 2014 at 06:04:35AM +, KY Srinivasan wrote: Greg has not committed these patches yet. One of the patches changes the balloon floor. This means that the guest will not be ballooned down below the floor. Is this what you are seeing? In our testing we did not see anything

Re: [PATCH] scsi:storvsc enable reading from VPD pages on SPC-2

On Wed, Dec 10, 2014 at 12:38:25AM -0800, Long Li wrote: MSFT targets currently claim SPC-2 compliance while they implement post SPC-2 features. With this patch we can correctly handle WRITE_SAME_16 issues. This patch fixes an issue where the flag is setup too late in drive initialization

bcache blocking ops and lockdep warnings

Hi, After doing make-bcache -B /dev/sdf make-bcache -C /dev/sdh ls -l /sys/fs/bcache echo 1110734d-230c-4b8f-a63d-dff472a0977b > /sys/block/bcache0/bcache/attach the following warnings were produced with a 3.18.0.x86_64-01967-g86c6a2f kernel: [ 75.218601] bcache: register_bdev() registered

bcache blocking ops and lockdep warnings

Hi, After doing make-bcache -B /dev/sdf make-bcache -C /dev/sdh ls -l /sys/fs/bcache echo 1110734d-230c-4b8f-a63d-dff472a0977b /sys/block/bcache0/bcache/attach the following warnings were produced with a 3.18.0.x86_64-01967-g86c6a2f kernel: [ 75.218601] bcache: register_bdev() registered

Re: [PATCH 3/3] Drivers: hv: hv_balloon: Don't post pressure status from interrupt context

read to post the status. > This will address the inconsistent lock state that Sitsofe Wheeler > > reported: Sorry I didn't follow up on this. Things looked better after the patch but I was seeing a strange issue where the memory was being reduced to some minimum and the balloon

Re: [PATCH 3/3] Drivers: hv: hv_balloon: Don't post pressure status from interrupt context

the status. This will address the inconsistent lock state that Sitsofe Wheeler sits...@gmail.com reported: Sorry I didn't follow up on this. Things looked better after the patch but I was seeing a strange issue where the memory was being reduced to some minimum and the balloon would never shrink so

Re: skbuff_fclone_cache poison overwritten

On 11 November 2014 19:27, Long Li wrote: > It's not obvious if this is a problem with hv_netvsc, or other code. > > Can you try to use a legacy network device and see if this issue still exists? Good point - I'll try that tomorrow (your guess that I was currently using

Re: skbuff_fclone_cache poison overwritten

On 11 November 2014 19:27, Long Li lon...@microsoft.com wrote: It's not obvious if this is a problem with hv_netvsc, or other code. Can you try to use a legacy network device and see if this issue still exists? Good point - I'll try that tomorrow (your guess that I was currently using

skbuff_fclone_cache poison overwritten

While using 3.18.0-rc3.x86_64-00116-g6ac94d3 on a Hyper-V 2012 R2 the poison in skbuff_fclone_cache was overwritten: [39099.484435] sd 7:0:0:0: [sdi] Attached SCSI disk [39099.484688] sd 6:0:0:0: [sdh] Attached SCSI disk [45285.786640]

skbuff_fclone_cache poison overwritten

While using 3.18.0-rc3.x86_64-00116-g6ac94d3 on a Hyper-V 2012 R2 the poison in skbuff_fclone_cache was overwritten: [39099.484435] sd 7:0:0:0: [sdi] Attached SCSI disk [39099.484688] sd 6:0:0:0: [sdh] Attached SCSI disk [45285.786640]

Inconsistent lock state with Hyper-V memory balloon?

I've been trying to use the Hyper-V balloon driver to allow the host to reclaim unused memory but have been hitting issues. With a Hyper-V 2012 R2 guest with 4GBytes of RAM, dynamic memory on, 1GByte minimum 10GByte maximum, 8 vcpus, running a 3.18.0-rc3 kernel with no swap configured the

Inconsistent lock state with Hyper-V memory balloon?

I've been trying to use the Hyper-V balloon driver to allow the host to reclaim unused memory but have been hitting issues. With a Hyper-V 2012 R2 guest with 4GBytes of RAM, dynamic memory on, 1GByte minimum 10GByte maximum, 8 vcpus, running a 3.18.0-rc3 kernel with no swap configured the

Re: [PATCH 0/3] scsi: Add Hyper-V logical block provisioning quirks

On 23 October 2014 02:50, Martin K. Petersen wrote: >>>>>> "Sitsofe" == Sitsofe Wheeler writes: > > Sitsofe> 2. On top of the above, when a disk is "small" (has less than > Sitsofe>2^32 sectors which is typically < 2 TBytes in

Re: [PATCH 0/3] scsi: Add Hyper-V logical block provisioning quirks

On 23 October 2014 02:50, Martin K. Petersen martin.peter...@oracle.com wrote: Sitsofe == Sitsofe Wheeler sits...@gmail.com writes: Sitsofe 2. On top of the above, when a disk is small (has less than Sitsofe2^32 sectors which is typically 2 TBytes in size) READ SitsofeCAPACITY(16

Re: [PATCH net 1/1] hyperv: Fix a bug in netvsc_send()

On 21 October 2014 18:13, Long Li wrote: > Thanks Sitsofe. This should have been fixed by this patch: > http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=f88e67149f97d73c704d6fe6f492edde97463025 > > Can you give it a try? Ah this one went mainline a few days ago so I've

Re: [PATCH net 1/1] hyperv: Fix a bug in netvsc_send()

On 21 October 2014 18:13, Long Li lon...@microsoft.com wrote: Thanks Sitsofe. This should have been fixed by this patch: http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=f88e67149f97d73c704d6fe6f492edde97463025 Can you give it a try? Ah this one went mainline a few

Re: [PATCH 0/3] scsi: Add Hyper-V logical block provisioning quirks

On Sun, Oct 12, 2014 at 01:21:01AM +, KY Srinivasan wrote: > > > -Original Message- > > From: Jeff Leung [mailto:jle...@v10networks.ca] > > Sent: Saturday, October 11, 2014 1:22 PM > > > > > On the current release of Windows (windows 10), we are advertising > > > SPC3 compliance. > >

Re: [PATCH 2/3] scsi: add try_rc16 blacklist flag

On Tue, Oct 14, 2014 at 09:08:28PM -0400, Martin K. Petersen wrote: > >>>>> "Sitsofe" == Sitsofe Wheeler writes: > > Sitsofe> Microsoft Hyper-V virtual disks currently only claim SPC-2 > Sitsofe> compliance causing the kernel skip checks for feature

Re: [PATCH 0/3] scsi: Add Hyper-V logical block provisioning quirks

On Tue, Oct 14, 2014 at 09:06:37PM -0400, Martin K. Petersen wrote: > >>>>> "Sitsofe" == Sitsofe Wheeler writes: > > Sitsofe> A previous patch attempted to add a quirk to workaround this > Sitsofe> but the quirk was only enabled after the features had

Re: [PATCH 0/3] scsi: Add Hyper-V logical block provisioning quirks

On Tue, Oct 14, 2014 at 09:06:37PM -0400, Martin K. Petersen wrote: Sitsofe == Sitsofe Wheeler sits...@gmail.com writes: Sitsofe A previous patch attempted to add a quirk to workaround this Sitsofe but the quirk was only enabled after the features had been Sitsofe scanned for, wouldn't work

Re: [PATCH 2/3] scsi: add try_rc16 blacklist flag

On Tue, Oct 14, 2014 at 09:08:28PM -0400, Martin K. Petersen wrote: Sitsofe == Sitsofe Wheeler sits...@gmail.com writes: Sitsofe Microsoft Hyper-V virtual disks currently only claim SPC-2 Sitsofe compliance causing the kernel skip checks for features such as Sitsofe thin provisioning even

Re: [PATCH 0/3] scsi: Add Hyper-V logical block provisioning quirks

On Sun, Oct 12, 2014 at 01:21:01AM +, KY Srinivasan wrote: -Original Message- From: Jeff Leung [mailto:jle...@v10networks.ca] Sent: Saturday, October 11, 2014 1:22 PM On the current release of Windows (windows 10), we are advertising SPC3 compliance. We are ok with

Re: [PATCH net 1/1] hyperv: Fix a bug in netvsc_send()

essage- > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf > Of Sitsofe Wheeler > Sent: Thursday, October 09, 2014 6:32 AM > To: David Miller > Cc: o...@aepfle.de; net...@vger.kernel.org; jasow...@redhat.com; > linux-kernel@vger.

Re: [PATCH net 1/1] hyperv: Fix a bug in netvsc_send()

[mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf Of Sitsofe Wheeler Sent: Thursday, October 09, 2014 6:32 AM To: David Miller Cc: o...@aepfle.de; net...@vger.kernel.org; jasow...@redhat.com; linux-kernel@vger.kernel.org; a...@canonical.com; de...@linuxdriverproject.org Subject

[PATCH 3/3] scsi: Use try_rc16 and try_vpd_pages quirks on Hyper-V virtual disks

impacts Hyper-V's VHD/VHDX virtual disks and not passthrough devices. Signed-off-by: Sitsofe Wheeler --- drivers/scsi/scsi_devinfo.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c index 49014a1..3eadcb1 100644 --- a/drivers/scsi

[PATCH 2/3] scsi: add try_rc16 blacklist flag

-by: Sitsofe Wheeler --- drivers/scsi/scsi_scan.c| 3 +++ drivers/scsi/sd.c | 3 +++ include/scsi/scsi_device.h | 1 + include/scsi/scsi_devinfo.h | 1 + 4 files changed, 8 insertions(+) diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c index ba3f1e8..d3f6267 100644

[PATCH 1/3] Revert "Drivers: add blist flags"

This reverts commit f3cfabce7a2e92564d380de3aad4b43901fb7ae6 (Drivers: add blist flags) as it does not enable thin provisioning for my Hyper-V 2012 R2 virtual disks. Signed-off-by: Sitsofe Wheeler --- drivers/scsi/storvsc_drv.c | 10 -- 1 file changed, 10 deletions(-) diff --git

[PATCH 0/3] scsi: Add Hyper-V logical block provisioning quirks

only Hyper-V virtual disks and work on small virtual disks. Sitsofe Wheeler (3): Revert "Drivers: add blist flags" scsi: add try_rc16 blacklist flag scsi: Use try_rc16 and try_vpd_pages quirks on Hyper-V virtual disks drivers/scsi/scsi_devinfo.c | 1 + drivers/scsi/scsi_scan.c

[PATCH 0/3] scsi: Add Hyper-V logical block provisioning quirks

virtual disks and work on small virtual disks. Sitsofe Wheeler (3): Revert Drivers: add blist flags scsi: add try_rc16 blacklist flag scsi: Use try_rc16 and try_vpd_pages quirks on Hyper-V virtual disks drivers/scsi/scsi_devinfo.c | 1 + drivers/scsi/scsi_scan.c| 3 +++ drivers/scsi

[PATCH 1/3] Revert Drivers: add blist flags

This reverts commit f3cfabce7a2e92564d380de3aad4b43901fb7ae6 (Drivers: add blist flags) as it does not enable thin provisioning for my Hyper-V 2012 R2 virtual disks. Signed-off-by: Sitsofe Wheeler sits...@yahoo.com --- drivers/scsi/storvsc_drv.c | 10 -- 1 file changed, 10 deletions

[PATCH 2/3] scsi: add try_rc16 blacklist flag

-by: Sitsofe Wheeler sits...@yahoo.com --- drivers/scsi/scsi_scan.c| 3 +++ drivers/scsi/sd.c | 3 +++ include/scsi/scsi_device.h | 1 + include/scsi/scsi_devinfo.h | 1 + 4 files changed, 8 insertions(+) diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c index ba3f1e8..d3f6267

[PATCH 3/3] scsi: Use try_rc16 and try_vpd_pages quirks on Hyper-V virtual disks

impacts Hyper-V's VHD/VHDX virtual disks and not passthrough devices. Signed-off-by: Sitsofe Wheeler sits...@yahoo.com --- drivers/scsi/scsi_devinfo.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c index 49014a1..3eadcb1 100644

Re: [PATCH net 1/1] hyperv: Fix a bug in netvsc_send()

On Sun, Oct 05, 2014 at 09:11:29PM -0400, David Miller wrote: > From: "K. Y. Srinivasan" > Date: Sun, 5 Oct 2014 10:42:51 -0700 > > > After the packet is successfully sent, we should not touch the packet > > as it may have been freed. This patch is based on the work done by > > Long Li . > >

Re: [PATCH net 1/1] hyperv: Fix a bug in netvsc_send()

On Sun, Oct 05, 2014 at 09:11:29PM -0400, David Miller wrote: From: K. Y. Srinivasan k...@microsoft.com Date: Sun, 5 Oct 2014 10:42:51 -0700 After the packet is successfully sent, we should not touch the packet as it may have been freed. This patch is based on the work done by Long Li

Re: [PATCH net 1/1 V2] hyperv: Fix a bug in netvsc_start_xmit()

from 0x8100 (relocation range: 0x8000-0x9fff) ---[ end Kernel panic - not syncing: Fatal exception in interrupt So Tested-by: Sitsofe Wheeler But I'm still seeing oopses like the following: BUG: unable to handle kernel paging request at 8800ec0b9073 IP: [] netvsc

Re: [PATCH net 1/1 V2] hyperv: Fix a bug in netvsc_start_xmit()

- not syncing: Fatal exception in interrupt Kernel Offset: 0x0 from 0x8100 (relocation range: 0x8000-0x9fff) ---[ end Kernel panic - not syncing: Fatal exception in interrupt So Tested-by: Sitsofe Wheeler sits...@yahoo.com But I'm still seeing oopses like the following

Re: Time keeps on slipping... on Hyper-V

t; > > -Original Message- > > From: Sitsofe Wheeler [mailto:sits...@gmail.com] > > Sent: Thursday, September 25, 2014 2:08 PM > > > > You [Microsoft?] do? Can you link to public sources where is this stated > > As far as I know, currently the document abou

Re: [PATCH] Drivers: hv: util: Implement Time Synchronization using host time sample

On Tue, Sep 23, 2014 at 09:56:10AM +0200, Olaf Hering wrote: > On Tue, Sep 23, Thomas Shao wrote: > > > In current hyper-v time sync service,it only gets the initial clock time > > from the host. It didn't process the following time samples. This change > > introduced a module parameter called

Re: [PATCH] Drivers: hv: util: Implement Time Synchronization using host time sample

On Tue, Sep 23, 2014 at 09:56:10AM +0200, Olaf Hering wrote: On Tue, Sep 23, Thomas Shao wrote: In current hyper-v time sync service,it only gets the initial clock time from the host. It didn't process the following time samples. This change introduced a module parameter called

Re: Time keeps on slipping... on Hyper-V

On Thu, Sep 25, 2014 at 09:40:42AM +, Thomas Shao wrote: On Tue, Sep 23, Thomas Shao wrote: with the host clock using host time sample. By default it is disabled, because we still recommend user to configure NTP for time -Original Message- From: Sitsofe Wheeler

Re: [PATCH 3.14 039/114] scsi: add a blacklist flag which enables VPD page inquiries

On Mon, Sep 15, 2014 at 12:25:39PM -0700, Greg Kroah-Hartman wrote: > 3.14-stable review patch. If anyone has any objections, please let me know. > > -- > > From: "Martin K. Petersen" > > commit c1d40a527e885a40bb9ea6c46a1b1145d42b66a0 upstream. > > Despite supporting modern

Re: [PATCH 3.14 039/114] scsi: add a blacklist flag which enables VPD page inquiries

On Mon, Sep 15, 2014 at 12:25:39PM -0700, Greg Kroah-Hartman wrote: 3.14-stable review patch. If anyone has any objections, please let me know. -- From: Martin K. Petersen martin.peter...@oracle.com commit c1d40a527e885a40bb9ea6c46a1b1145d42b66a0 upstream. Despite

  1   2   3   >