Ilya Leoshkevich wrote on Tue, Nov 26, 2024 at 10:24:12AM +0100:
> I think this is
> https://gitlab.com/qemu-project/qemu/-/issues/1913
Thank you, I should have looked there first !
I'll continue to follow-up on the issue if time permits as it doesn't
look like this has had progress in the past f
This commit is fairly old, but this appears to cause a segfault for
older versions of ldconfig:
```
$ docker run --rm --platform linux/arm64/v8 -ti docker.io/debian:bullseye-slim
ldconfig
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)
```
The s
Stefan Hajnoczi wrote on Wed, Jul 06, 2022 at 08:17:42AM +0100:
> Great! I've already queued your fix.
Thanks!
> Do you want to send a follow-up that updates the comment?
I don't think I'd add much value at this point, leaving it to you unless
you really would prefer me to send it.
Cheers,
--
Stefan Hajnoczi wrote on Tue, Jul 05, 2022 at 02:28:08PM +0100:
> > The older kernel I have installed right now is 5.16 and that can
> > reproduce it -- I'll give my laptop some work over the weekend to test
> > still maintained stable branches if that's useful.
>
> Linux 5.16 contains commit 9d9
Dominique Martinet wrote on Fri, Jul 01, 2022 at 07:52:31AM +0900:
> Stefano Garzarella wrote on Thu, Jun 30, 2022 at 05:49:21PM +0200:
> > > so when we ask for more we issue an extra short reads, making sure we go
> > > through the two short reads path.
> > > (Unf
Stefano Garzarella wrote on Thu, Jun 30, 2022 at 05:49:21PM +0200:
> > so when we ask for more we issue an extra short reads, making sure we go
> > through the two short reads path.
> > (Unfortunately I wasn't quite sure what to fiddle with to issue short
> > reads in the first place, I tried cutti
we should fix this.
This lead to weird image corruptions when short read happened
Fixes: 6663a0a33764 ("block/io_uring: implements interfaces for io_uring")
Link: https://lkml.kernel.org/r/yrrfgo4a1js0g...@atmark-techno.com
Signed-off-by: Dominique Martinet
---
v1 -> v2: also updated
btrfs with O_DIRECT (cache=none) does.
This lead to weird image corruptions when short read happened
Fixes: 6663a0a33764 ("block/io_uring: implements interfaces for io_uring")
Link: https://lkml.kernel.org/r/yrrfgo4a1js0g...@atmark-techno.com
Signed-off-by: Dominique Martinet
---
Forgive the do
Kevin Wolf wrote on Wed, Jun 29, 2022 at 10:46:08AM +0200:
> I see this a few lines above:
>
> /* Update read position */
> luringcb->total_read = nread;
>
> Doesn't it have the same problem? Though maybe getting two short reads
> is more of a theoretical case.
Good catch, I'll send a v2
btrfs with O_DIRECT (cache=none) does.
This lead to weird image corruptions when short read happened
Fixes: 6663a0a33764 ("block/io_uring: implements interfaces for io_uring")
Link: https://lkml.kernel.org/r/yrrfgo4a1js0g...@atmark-techno.com
Signed-off-by: Dominique Martinet
---
I just spent
Christian Schoenebeck wrote on Fri, Apr 22, 2022 at 08:02:46PM +0200:
> So maybe it's better to handle case-insensitivity entirely on client side?
> I've read that some generic "case fold" code has landed in the Linux kernel
> recently that might do the trick?
I haven't tried, but settings S_CAS
Christian Schoenebeck wrote on Wed, Mar 03, 2021 at 03:04:21PM +0100:
> > We can definitely increase the default, for all transports in my
> > opinion.
> > As a first step, 64 or 128k?
>
> Just to throw some numbers first; when linearly reading a 12 GB file on guest
> (i.e. "time cat test.dat > /
Christian Schoenebeck wrote on Fri, Feb 26, 2021 at 02:49:12PM +0100:
> Right now the client uses a hard coded amount of 128 elements. So what about
> replacing VIRTQUEUE_NUM by a variable which is initialized with a value
> according to the user's requested 'msize' option at init time?
>
> Accord
Christian Schoenebeck wrote on Wed, Feb 24, 2021 at 04:16:52PM +0100:
> Misapprehension + typo(s) in my previous message, sorry Michael. That's 500k
> of course (not 5k), yes.
>
> Let me rephrase that question: are you aware of something in virtio that
> would
> per se mandate an absolute hard
Pavel Tatashin wrote on Mon, Jan 07, 2019:
> I did exactly the same sequence on Kaby Lake CPU and could not
> reproduce it. What is your host CPU?
skylake consumer laptop CPU: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
I don't have any kaby lake around; I have access to older servers though...
--
Pavel Tatashin wrote on Mon, Jan 07, 2019:
> I could not reproduce the problem. Did you suspend to memory between
> wake ups? Does this time jump happen every time, even if your laptop
> sleeps for a minute?
I'm not sure I understand "suspend to memory between the wake ups".
The full sequence is:
Pavel Tatashin wrote on Thu, Jan 03, 2019:
> Could you please send the config file and qemu arguments that were
> used to reproduce this problem.
Running qemu by hand, nothing fancy e.g. this works:
# qemu-system-x86_64 -m 1G -smp 4 -drive
file=/root/kvm-wrapper/disks/f2.img,if=virtio -serial mo
Theodore Y. Ts'o wrote on Fri, Dec 28, 2018:
> On Sat, Dec 29, 2018 at 03:37:21AM +0100, Dominique Martinet wrote:
> > > Are there going to be cases where a process or a thread will sometimes
> > > want the 64-bit interface, and sometimes want the 32-bit interface?
>
waste even if we
only do it for processes in 32bit mode, and a new flag would be a
protocol change with 9p not being designed to catter for subtle protocol
changes so would be rather painful to roll out)
No bright idea here, sorry.
--
Dominique Martinet | Asmadeus
hed_clock_running is set adjust scd */
> + local_irq_save(flags);
> + sched_clock_tick();
> + local_irq_restore(flags);
> }
> /*
> * We run this as late_initcall() such that it runs after all built-in
> drivers,
> @@ -356,7 +374,7 @@ u64 sched_clock_cpu(int cpu)
> return sched_clock() + __sched_clock_offset;
>
> if (unlikely(!sched_clock_running))
> - return 0ull;
> + return sched_clock();
>
> preempt_disable_notrace();
> scd = cpu_sdc(cpu);
--
Dominique Martinet | Asmadeus
Hi Greg,
Greg Kurz wrote on Mon, Jul 04, 2016 at 05:08:49PM +0200:
> On Mon, 4 Jul 2016 16:16:55 +0200
> Dominique Martinet wrote:
>
> > I *think* this introduces a race somewhere, I'm getting errors like:
> > cat: f.05: No such file or directory
> > cat: f.14: N
I *think* this introduces a race somewhere, I'm getting errors like:
cat: f.05: No such file or directory
cat: f.14: No such file or directory
cat: f.13: No such file or directory
cat: f.39: No such file or directory
cat: f.05: No such file or directory
when doing:
for file in {01..50}; do to
cking myself out of my test box pretty quickly.
I'll try to debug patches a bit more individually (trying everything at
once isn't helping), but at the very least something is fishy
--
Dominique Martinet
Hi,
for what it's worth, the sample code given works with nfs-ganesha
server, so I'm not sure what's not working here.
Here's the server traces:
TATTACH: tag=1 fid=0 afid=-1 uname='nobody' aname='/export' n_uname=-1
RATTACH: tag=1 fid=0 qid=(type=128,version=0,path=1)
TGETATTR: tag=1 fid=0 reques
Hi,
Christopher Covington wrote on Fri, Aug 22, 2014 at 08:37:52AM -0400:
> Thanks for the pointer to this patch. I think I started this kernel half way
> through the 3.16 merge window. The last non-cherry-picked patch I have is:
>
> commit 6d87c225f5d82d29243dc124f1ffcbb0e14ec358
>
> So I do ha
(i440FX + PIIX, 1996), BIOS
> rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
I'm pretty sure that's the same problem that's been reported a few times
here, could you try again after cherry-picking this commit:
commit f15844e0777fec936f87a87f97394f83911dacd
26 matches
Mail list logo
