IRC channel logs


back to list of logs

<solid_black>hi damo22
<damo22>i think git-send-email is adding "Content-Transfer-Encoding: quoted-printable"
<damo22>but i cant find its script
<solid_black>it's in /libexec/git-core/git-send-email here
<damo22> transferEncoding = 8bit
<damo22>that should work
<damo22>ok i think it should be fixed
<damo22>Add this to .gitconfig
<damo22> transferEncoding = 8bit
<solid_black>not that I know anything about email, but isn't it an issue with git-am if it fails to apply patches encoded in a standard-conforming way (moreover, the one that git's own tooling emits)?
<damo22>i think its because Samuel prefers to read patches manually
<solid_black>it's content *transfer* encoding, no? shouldn't it be *decoded* before it tries to apply the patch?
<solid_black>same there, shouldn't your email client decode it before displaying it to the user?
<damo22>he probably reads them in plain text mbox format
<damo22>also why encode the message it should be displayed as written
<damo22>if i was on the receiving end of patches, i would want to be able to read them in vim
<damo22>just like the patch i sent
<solid_black>certainly it should be easy to view patches and edit them in vim and apply them; I'm not saying that it should not be
<etno>damo22: I have been trying to reproduce the "invalid FPU state" with qemu SMP on top of your latest fix-ioapic. I could not, but then I realized that you are doing this in x86_64. Is this correct?
<damo22>i am using i386
<damo22>how are you launching qemu?
<damo22>etno: a lot of this is probably unnecessary, but i can share my qemu command:
<damo22>qemu-system-i386 -M q35,accel=kvm -m 4096 -smp 2 -net user,hostfwd=tcp::8888-:22 -net nic -curses -hda /dev/sda \
<damo22> -cpu Penryn,kvm=on,vendor=GenuineIntel,vmware-cpuid-freq=on,+ssse3,+sse4.2,+popcnt,+avx,+aes,+xsave,+xsaveopt,check
<etno>qemu-system-i386 --accel tcg -m 1G -M q35 -smp 2 -s -S -drive format=raw,file=...
<damo22>the reason i use the cpu flags is because i am actually hosting it on amd cpu and i want to emulate a proper intel cpu
<etno>I am running on an Intel N4200
<damo22>what is tcg?
<etno>This is the jit recompiler accelerator. I need this for breakpoints to work, it seems
<damo22>thats neat
<etno>QEMU 5.2.0
<damo22>how does it compare in speed to kvm
<etno>Much slower, I would say
<etno>But for gnumach, it is not really an issue
<etno>I am worried that I made your life harder with this FPU patch...
<damo22>not at all
<damo22>its a simple revert if i need to
<damo22>but i dont understand it
<etno>If you want to take time, I can explain it. This may help to spot what could be wrong. As you like
<damo22>up to you
<damo22>you removed a cpuid instruction
<damo22>is that right?
<damo22>we are talking about commit f8d0f98e80b3 ?
<etno>Yes, because it was replacing the eax value we use further down
<etno>f8d0... yes
<etno>Here is the code, before:
<etno>Look at the eax test at 200
<etno>This is supposed to test cpuid (0xd,0x1) as at 180
<etno>But when the test with the panic message was inserted, it added a cpuid call with (0xd, 0x0) at 191
<youpi>the eax part is clearly wrong, yes
<youpi>one thing that gets different, though, is the ebx part
<youpi>we used to use ebx from the 0xd,0x1 cpuid
<youpi>for the offsetof computation
<youpi>while now we are using ebx from the 0xd,0x0 puid
<youpi>possibly it's something etno didn't realize would change
<youpi>I thought he noticed, but possibly not
<etno>One of the size checks was using the bitfield, instead of the flu state length
<youpi>? they're both using ebx
<youpi>either from 0xd,0x1 cpuid, or 0xd,0x0 cpuid
<damo22>the ebx cant be correct in both cases
<damo22>ie, before and after the change
<damo22>unless it was previously incorrect and your change fixes it
<youpi>the difference is IA32_XSS
<youpi>which we don't seem to be using
<youpi>damo22: you could try to restore
<youpi>+ fp_xsave_size = offsetof(struct i386_fpsave_state, xfp_save_state) + ebx;
<youpi>+ if (fp_xsave_size < sizeof(struct i386_fpsave_state))
<youpi>+ panic("CPU-provided xstate size %d " etc.
<youpi>in the if (eax & CPU_FEATURE_XSAVES) { branch
<etno>I based my changes on p823 content:
<damo22>fp_load: invalid FPU state!
<damo22>no panic
<damo22>im going to remove all my cpu flags
<damo22>that fixed it
<etno>youpi: should the size test be using (D,0)/ebx or (D,1)/ebx ? I must admit that I don't really understand the purpose of the test
<etno>Ohhhhhhh, it depends on the features ? That would make my patch partially wrong. And this is probably what you mean by "the difference is IA32_XSS", youpi
<etno>sneek: later tell youpi: I will try to issue a fix for the ebx misuse I introduced
<sneek>Got it.
<etno>damo22: could it be that, while the cpuid options in qemu are able to change what the guest sees returned by a CPUID call (trap and simulated), with KVM the instructions hit the actual CPU and then a mismatch occurs ?
<etno>Maybe with a fully emulated CPU, the features would match with the qemu options
<youpi>damo22: not sure what you tested, did the partial revert I suggested not work?
<sneek>Welcome back youpi, you have 1 message!
<sneek>youpi, etno says: I will try to issue a fix for the ebx misuse I introduced
<damo22>youpi: i tested your suggested change, it seemed to make no difference, but i removed all my -cpu flags in qemu and that fixed it
<damo22>however, etno says he thinks there is a problem with his change regarding ebx as well
<damo22>maybe i cannot emulate flags that do not exist in the host, but i did add "check" flag so that should tell me, no?
<youpi>it should tell you yes
<youpi>removing flags removes features and thus probably you simply don't hit the XSAVES case any more
<youpi>damo22: I guess if you disable the xsaves branch things work with all your flags?
<damo22>"disable the xsaves branch" i dont follow
<damo22>you mean remove the if
<youpi> if (eax & CPU_FEATURE_XSAVES) {
<youpi>put a && 0 here
<damo22>sorry i rebased master it will take a while to compile
<damo22>no it still occurs
<anatoly>solid_black: oh yeah, it booted
<damo22>youpi: +xsave,+xsaveopt
<damo22>these two flags probably break it
<solid_black>hi anatoly!
<damo22>bugs : fxsave_leak
<solid_black>how far did it get? did I push the version that boots with OpenRC, or are you just booting with init=/bin/sh?
<anatoly>solid_black: I'm on older commit so tried only /bin/sh. Will rebuild tomorrow and try again
<solid_black>I should push my latest changes too
<solid_black>I have tried building dde/netdde, but it doesn't succeed yet
<etno>youpi: I have difficulties understanding the check in init_fpu(). AIUI, fp_xsave_size is the size i386_fpsave_state should be to contain all of the FPU state. But the current code is making sure that fp_xsave_size is bigger or equal. I can make sense only of equality, because otherwise things would overflow the structure.
<youpi>etno: no, not all
<youpi>xsaves & co are precisely meant for the OS not to actually have to know ahead of runtime how much room will be needed
<youpi>the check is just there to make sure the value is not completely bogus
<etno>ACTION realizes suddenly that fp_xsave_size is not a local variable
<etno>youpi: thanks for the explanation