Le ven. 15 mai 2020 à 15:53, Jonathan A. Kollasch
a écrit :
>
> On Sat, May 02, 2020 at 12:02:45PM +1000, Paul Ripke wrote:
> > Since I have my qemu disk images on slow spinning rust host disks, when the
> > host disk is busy (esp. daily+security runs), I find my qemu vm's see disk
> > timeouts, a
On Sat, May 02, 2020 at 12:02:45PM +1000, Paul Ripke wrote:
> Since I have my qemu disk images on slow spinning rust host disks, when the
> host disk is busy (esp. daily+security runs), I find my qemu vm's see disk
> timeouts, and end up crashing. This isn't great behaviour.
Timeout issue aside, c
On Thu, May 14, 2020 at 03:32:51PM +0200, Jaromír Doleček wrote:
> Le jeu. 14 mai 2020 à 15:19, a écrit :
> > > Bumped ATA_DELAY to 3 (was 1), and the VM stayed up overnight,
> > > only logging the one correctable soft error:
> > >
> > > May 7 04:19:29 qemu /netbsd: [ 16290.3345912] autoc
On Thu, May 14, 2020 at 08:26:48PM +0200, Manuel Bouyer wrote:
> On Thu, May 14, 2020 at 03:32:51PM +0200, Jaromír Dole?ek wrote:
> > [...]
> > Seriously though I think that it wouldn't hurt to just bump ATA_DELAY
> > to 30 seconds by default.
>
> I don't remember if it's used only for I/O or also
On Thu, May 14, 2020 at 03:32:51PM +0200, Jaromír Dole?ek wrote:
> [...]
> Seriously though I think that it wouldn't hurt to just bump ATA_DELAY
> to 30 seconds by default.
I don't remember if it's used only for I/O or also for probe.
If the later, it could take 3x more time to boot ...
--
Manue
On Thu, May 14, 2020 at 03:32:51PM +0200, Jaromír Doleček wrote:
> Le jeu. 14 mai 2020 à 15:19, a écrit :
> > > Bumped ATA_DELAY to 3 (was 1), and the VM stayed up overnight,
> > > only logging the one correctable soft error:
> > >
> > > May 7 04:19:29 qemu /netbsd: [ 16290.3345912] autoc
Le jeu. 14 mai 2020 à 15:19, a écrit :
> > Bumped ATA_DELAY to 3 (was 1), and the VM stayed up overnight,
> > only logging the one correctable soft error:
> >
> > May 7 04:19:29 qemu /netbsd: [ 16290.3345912] autoconfiguration error:
> > piixide0:0:0: lost interrupt
> > May 7 04:19:29 q
On 14/05/2020 14:19, m...@netbsd.org wrote:
QEMU emulation isn't a niche setup, we should aim to have it work out of
the box without adjusting sysctls, IMO.
I'd agree with that. Perhaps the real question to ask here is why is a
QEMU ATA operation taking 30 seconds to complete in the first p
On Thu, May 07, 2020 at 08:49:19AM +1000, Paul Ripke wrote:
> On Sat, May 02, 2020 at 12:02:45PM +1000, Paul Ripke wrote:
> > Since I have my qemu disk images on slow spinning rust host disks, when the
> > host disk is busy (esp. daily+security runs), I find my qemu vm's see disk
> > timeouts, and
On Thu, May 07, 2020 at 05:11:54PM -, Michael van Elst wrote:
> s...@stix.id.au (Paul Ripke) writes:
>
> >Would making ATA_DELAY configurable via options(4) be worth it?
>
> That, and maybe even a sysctl.
How about this attached patch? Made it a per-device sysctl knob,
and renamed other misc
s...@stix.id.au (Paul Ripke) writes:
>Would making ATA_DELAY configurable via options(4) be worth it?
That, and maybe even a sysctl.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
On Sat, May 02, 2020 at 12:02:45PM +1000, Paul Ripke wrote:
> Since I have my qemu disk images on slow spinning rust host disks, when the
> host disk is busy (esp. daily+security runs), I find my qemu vm's see disk
> timeouts, and end up crashing. This isn't great behaviour.
>
> Is anyone else see
Since I have my qemu disk images on slow spinning rust host disks, when the
host disk is busy (esp. daily+security runs), I find my qemu vm's see disk
timeouts, and end up crashing. This isn't great behaviour.
Is anyone else seeing this? Any workarounds? I haven't looked, but I assume
I'd be able
13 matches
Mail list logo