[valgrind] [Bug 418756] New: MAP_FIXED_NOREPLACE mmap flag unsupported

https://bugs.kde.org/show_bug.cgi?id=418756 Bug ID: 418756 Summary: MAP_FIXED_NOREPLACE mmap flag unsupported Product: valgrind Version: 3.15 SVN Platform: Other OS: Linux Status: REPORTED Severity:

Re: [Freedos-devel] Centroid command.com license confirmed

Hi, 15.03.2019 4:30, Rugxulo пишет: Hi, Stas, On Thu, Mar 14, 2019 at 5:56 PM Stas Sergeev wrote: As you probably know, once upon a time (like 20 years ago) there were the command.com sources from Centroid Corp under GPL. AFAIK they were removed from the freedos servers because

Re: [freedos-32-dev] [Freedos-devel] Centroid command.com license confirmed

Hi, 15.03.2019 4:30, Rugxulo пишет: Hi, Stas, On Thu, Mar 14, 2019 at 5:56 PM Stas Sergeev wrote: As you probably know, once upon a time (like 20 years ago) there were the command.com sources from Centroid Corp under GPL. AFAIK they were removed from the freedos servers because

Re: [Freedos-devel] Centroid command.com license confirmed

15.03.2019 2:45, Stas Sergeev пишет: 15.03.2019 2:23, Tom Ehlert пишет: PLEASE.GO.AWAY. (and stay there for the rest of my life) I think you are absolutely obtuse if you think I asked you what I should do. Because obviously what I wanted to do is to notify everyone who hosted that code

Re: [Freedos-devel] Centroid command.com license confirmed

15.03.2019 2:23, Tom Ehlert пишет: FreeDOS is NOT the kitchen sink where to dump 20 years old, buggy software as long as it has a GPL3 license attached. Not sure why should I reply to the crap like this, but here's the proof: https://sourceforge.net/p/freedos-32/mailman/message/3995210/ ---

[Freedos-devel] Centroid command.com license confirmed

Hello freedos developers & users. As you probably know, once upon a time (like 20 years ago) there were the command.com sources from Centroid Corp under GPL. AFAIK they were removed from the freedos servers because of the licence uncertaincy. I used them in my comcom32 project:

[freedos-32-dev] Centroid command.com license confirmed

Hello freedos developers & users. As you probably know, once upon a time (like 20 years ago) there were the command.com sources from Centroid Corp under GPL. AFAIK they were removed from the freedos servers because of the licence uncertaincy. I used them in my comcom32 project:

Re: SoundBlaster drivers

28.01.2019 2:40, Brent Busby пишет: SoundBlaster drivers bundled with Windows 3.1? https://www.pcjs.org/disks/pcx86/windows/3.10/ Disk 3 contains |SNDBLST DR_ 10122 03-10-92 3:10a | |||SNDBLST2 DR_ 10445 03-10-92 3:10a| | ||Google has all answers, try things out. |

Re: SoundBlaster drivers

27.01.2019 5:01, Brent Busby пишет: That explains why MIDI seems to work in bare DOS -- because the BLASTER command from DOSEMU is providing everything needed for sound, at least for DOS. I thought I needed drivers though because Windows 3.1 isn't seeing any sound or MIDI on its own though. So

Re: SoundBlaster drivers

27.01.2019 2:54, Brent Busby пишет: I'm trying to install SoundBlaster drivers inside the DOSEMU emulation. No, you don't need to install any drivers, because the default autoexec.bat of dosemu is doing all the needed work. However, installing the drivers should be possible, and if it hangs,

Re: FW: DOSEMU

21.12.2018 16:40, adrian wilkins пишет: Multiple Windows-based terminals local area networked into a Linux file server running Samba.  All the above locking systems work OK. Multiple Windows-based terminals running PUTTY into multiple copies of DOSEMU on a Linux server. All the above locking

Re: dosemu, Putty, ERROR: X

19.10.2018 9:28, Alex пишет: Dear all, I am just starting using dosemu. I have Debian 8 guest running in VirtualBox and am connecting to it using Putty on Windows7 host. While trying to execute "dosemu remdir_c.bat" that calls DOS exe file I am getting following error:

Re: quick question about dosemu

25.09.2018 1:49, David Henderson пишет: Thanks for the tip Stuart, I'll see if I can touch base with the author(s)! What's the use of contacting the authors, instead of trying things out on your own? This is the best way of getting no help at all, unless you contact the paid support, like

Re: quick question about dosemu

24.09.2018 23:01, David Henderson пишет: So I have bad news... I tried both dosemu and wine, but neither will run chkdsk. I even tried using another wine binary called wineconsole - no go there either. This sucks!!! But at least there is confirmation that it will not work. Wine is not going

Re: quick question about dosemu

20.09.2018 23:42, David Henderson пишет: Good afternoon! I am working on a project that I would need to run some DOS executables from the Linux command line (e.g. chkdsk.exe). I briefly looked at DosBox, but it requires a GUI environment and is geared towards games. Does dosemu allow me to run

[valgrind] [Bug 398445] uninitialized memory false reports on shared memory

https://bugs.kde.org/show_bug.cgi?id=398445 --- Comment #17 from Stas Sergeev --- (In reply to Philippe Waroquiers from comment #16) > That might not be straightforward to do, in particular if you have > multiple threads (you probably need a critical section around the > write o

[valgrind] [Bug 398445] uninitialized memory false reports on shared memory

https://bugs.kde.org/show_bug.cgi?id=398445 --- Comment #15 from Stas Sergeev --- (In reply to Philippe Waroquiers from comment #14) > So, IMO, the easiest is to use the client requests Which ones? I did all the modifications you asked for, they all in my latest test-case. > (the do

[valgrind] [Bug 398445] uninitialized memory false reports on shared memory

https://bugs.kde.org/show_bug.cgi?id=398445 --- Comment #13 from Stas Sergeev --- Will it help to print an additional warning when the uninitialized mem is copied to the shared region? The chances are very high this will result in a false-positives later, so maybe catching it at that stage would

[valgrind] [Bug 398445] uninitialized memory false reports on shared memory

https://bugs.kde.org/show_bug.cgi?id=398445 --- Comment #11 from Stas Sergeev --- (In reply to Philippe Waroquiers from comment #10) > If you declare the memory initialised before forking, > using VALGRIND_MAKE_MEM_DEFINED() ... which is what my latest test-case already does. Please sugge

[valgrind] [Bug 398445] uninitialized memory false reports on shared memory

https://bugs.kde.org/show_bug.cgi?id=398445 --- Comment #9 from Stas Sergeev --- (In reply to Ivo Raisr from comment #6) > Yes, indeed. That's why we have syscall and ioctl wrappers in Valgrind. > They describe what the other side (kernel) expects from the buffers sent > there >

[valgrind] [Bug 398445] uninitialized memory false reports on shared memory

https://bugs.kde.org/show_bug.cgi?id=398445 --- Comment #8 from Stas Sergeev --- (In reply to Philippe Waroquiers from comment #7) > If mmap would necessarily zero out memory, then > that would create major difficulties to use > shared memory. > I think that what the kerne

[valgrind] [Bug 398445] uninitialized memory false reports on shared memory

https://bugs.kde.org/show_bug.cgi?id=398445 --- Comment #5 from Stas Sergeev --- Think of the following use-case. Consider a very silly shm IPC that uses just one large struct with many input and output fields. Client fills in the output fields and copies the entire struct to the shm buffer

[valgrind] [Bug 398445] uninitialized memory false reports on shared memory

https://bugs.kde.org/show_bug.cgi?id=398445 --- Comment #4 from Stas Sergeev --- Created attachment 114906 --> https://bugs.kde.org/attachment.cgi?id=114906=edit 2 processes and VALGRIND_MAKE_MEM_DEFINED (In reply to Philippe Waroquiers from comment #3) > It is not very clear to m

[valgrind] [Bug 398445] uninitialized memory false reports on shared memory

https://bugs.kde.org/show_bug.cgi?id=398445 --- Comment #2 from Stas Sergeev --- Created attachment 114889 --> https://bugs.kde.org/attachment.cgi?id=114889=edit 2-process test-case Hi, thanks for your reply. Here is the test-case that does the same thing but with 2 processes scheme. S

[valgrind] [Bug 398445] uninitialized memory false reports on shared memory

https://bugs.kde.org/show_bug.cgi?id=398445 Stas Sergeev changed: What|Removed |Added Version|unspecified |3.13.0 -- You are receiving this mail because

[valgrind] [Bug 398445] New: uninitialized memory false reports on shared memory

https://bugs.kde.org/show_bug.cgi?id=398445 Bug ID: 398445 Summary: uninitialized memory false reports on shared memory Product: valgrind Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED

[Freedos-kernel] announce: fdpp, a 64bit DOS in C++

Hi all DOS fans! After a year of development, I am glad to announce the new 64bit DOS. But as we know, all new is well-forgotten old, so this actually is a freedos kernel port to 64 bits. Some of you have probably already heard about this project, as it was pre-announced on fosdem-18, but at

announce: fdpp, a 64bit DOS in C++

Hi all DOS fans! After a year of development, I am glad to announce the new 64bit DOS. But as we know, all new is well-forgotten old, so this actually is a freedos kernel port to 64 bits. Some of you have probably already heard about this project, as it was pre-announced on fosdem-18, but at

announce: fdpp, a 64bit DOS in C++

Hi all DOS fans! After a year of development, I am glad to announce the new 64bit DOS. But as we know, all new is well-forgotten old, so this actually is a freedos kernel port to 64 bits. Some of you have probably already heard about this project, as it was pre-announced on fosdem-18, but at

[bug #49814] vbe does not reset display start

Follow-up Comment #7, bug #49814 (project grub): Oops, please use patch from this comment (prev one was bad). (file #44510) ___ Additional Item Attachment: File name: 0001-reset-display_start-before-switching-mode.patch Size:1 KB

[bug #49814] vbe does not reset display start

Follow-up Comment #6, bug #49814 (project grub): As this bug keeps hitting all i915 notebooks (read: all notebooks), I had to dig a bit more. The fix is attached. > May be we need wrapper around ->fini() method that resets > current page (moving code from > grub_video_fb_get_info_and_fini()). I

Re: Setting up dosemu2 (from binary)

26.06.2018 03:18, Richard White пишет: Hi! I have just joined github at Andrew Bird's suggestion because I need to run legacy DOS software on a 64-bit system. I'm a relative newbie, but have been very happily running dosemu2 for more than 1 year. Installed via deb created from binaries.

Re: FOSDEM talk next week

28.01.2018 20:47, j...@astro.princeton.edu пишет: Hi, Bart. I have been using (and absolutely depending on) dosemu/freedos for more than 15 years. I use a DOS CADD program called Generic Cadd for the design of electronics and astronomical instruments, which I started using probably 30 years

Re: Documenting sigaltstack SS_AUTODISRM

07.11.2017 01:26, Michael Kerrisk (man-pages) пишет: Hello Stas, Ping on the below? Hi, the change with the "not recommended" warning looks good to me. Acked-by: Stas Sergeev <s...@list.ru>

Re: Documenting sigaltstack SS_AUTODISRM

07.11.2017 01:26, Michael Kerrisk (man-pages) пишет: Hello Stas, Ping on the below? Hi, the change with the "not recommended" warning looks good to me. Acked-by: Stas Sergeev

Re: Documenting sigaltstack SS_AUTODISRM

30.10.2017 13:50, Michael Kerrisk (man-pages) пишет: I see what you mean. The point is back then that SS_ONSTACK was the only flag that could (on Linux) be specified in ss.ss_flags, so that "SS_ONSTACK | SOMETHING_FLAG" was a nonexistent case. These days, it's possible to specify the new

Re: Documenting sigaltstack SS_AUTODISRM

30.10.2017 13:50, Michael Kerrisk (man-pages) пишет: I see what you mean. The point is back then that SS_ONSTACK was the only flag that could (on Linux) be specified in ss.ss_flags, so that "SS_ONSTACK | SOMETHING_FLAG" was a nonexistent case. These days, it's possible to specify the new

[bug #51750] multiboot: grub ignores gfxpayload=keep

Follow-up Comment #5, bug #51750 (project grub): Please find it attached. With a lot of distro-specific noise, as usual. (file #41518) ___ Additional Item Attachment: File name: grub.cfg Size:2 KB

[bug #51750] multiboot: grub ignores gfxpayload=keep

Follow-up Comment #3, bug #51750 (project grub): So I swapped the strings to look like this: menuentry 'KOS_64' { recordfail load_video multiboot /boot/x86_64-vmkos.img set gfxmode=1024x768x32 set gfxpayload=keep boot } But this didn't change

[bug #51750] multiboot: grub ignores gfxpayload=keep

Follow-up Comment #2, bug #51750 (project grub): It was before. Never thought this matters. Will try swapping them. ___ Reply to this item at: ___

[bug #51750] multiboot: grub ignores gfxpayload=keep

URL: Summary: multiboot: grub ignores gfxpayload=keep Project: GNU GRUB Submitted by: stsp Submitted on: Mon 14 Aug 2017 02:19:50 PM UTC Category: Terminal Severity:

[bug #51466] grub ignores gfxpayload=keep

Follow-up Comment #2, bug #51466 (project grub): But this is not the problem I was actually reporting. Please see the quote below: --- The worse problem is that if you set the flag to request the gfx mode but in the multiboot header set the mode parameters to 0 for auto, you hope that in this

Re: FSGSBASE ABI considerations

07.08.2017 19:20, Andy Lutomirski пишет: I think this is the half-step. It clearly shows that you don't want such state to ever exist, but why not to go a step further and just make the bases to be reset not only by any unrelated modify_ldt() call, but always on schedule? You can state that

Re: FSGSBASE ABI considerations

07.08.2017 19:20, Andy Lutomirski пишет: I think this is the half-step. It clearly shows that you don't want such state to ever exist, but why not to go a step further and just make the bases to be reset not only by any unrelated modify_ldt() call, but always on schedule? You can state that

Re: FSGSBASE ABI considerations

Hello. 31.07.2017 06:05, Andy Lutomirski пишет: - User code can use the new RD/WR FS/GS BASE instructions. Apparently some users really want this for, umm, userspace threading. Think Java. I wonder how java avoids the lack of the user-space continuations support while getting the userspace

Re: FSGSBASE ABI considerations

Hello. 31.07.2017 06:05, Andy Lutomirski пишет: - User code can use the new RD/WR FS/GS BASE instructions. Apparently some users really want this for, umm, userspace threading. Think Java. I wonder how java avoids the lack of the user-space continuations support while getting the userspace

Re: [Bug-tar] transform with add-file seems broken

26.07.2017 17:59, Dominique Martinet пишет: Hi, Stas Sergeev wrote on Wed, Jul 26, 2017 at 05:22:56PM +0300: I am doing the following: $ tar cf a.tar a.txt $ tar rf a.tar --add-file=`pwd`/b.txt --transform=s,`pwd`/,aaa/, tar: Removing leading `/' from member names The transform is completely

Re: [Bug-tar] transform with add-file seems broken

26.07.2017 17:59, Dominique Martinet пишет: Hi, Stas Sergeev wrote on Wed, Jul 26, 2017 at 05:22:56PM +0300: I am doing the following: $ tar cf a.tar a.txt $ tar rf a.tar --add-file=`pwd`/b.txt --transform=s,`pwd`/,aaa/, tar: Removing leading `/' from member names The transform is completely

Re: git gc seems to break --symbolic-full-name

26.07.2017 16:23, Jeff King пишет: In git.git we do something like: -- >8 -- other: version cat $< >$@ .PHONY: FORCE version: FORCE @git rev-parse HEAD >$@+ @if cmp $@+ $@ >/dev/null 2>&1; then rm $@+; else mv $@+ $@; fi -- >8 -- Yes, thats a nice recipe that I would

[Bug-tar] transform with add-file seems broken

Hello. I am doing the following: $ tar cf a.tar a.txt $ tar rf a.tar --add-file=`pwd`/b.txt --transform=s,`pwd`/,aaa/, tar: Removing leading `/' from member names The transform is completely ignored, and tar complains to leading slash. But the following case works fine: $ tar cf a.tar a.txt $

Re: git gc seems to break --symbolic-full-name

26.07.2017 03:36, Jacob Keller пишет: If your goal is to make it so users filling out bug reports have a version, then using git descrsibe and making that be part of your version (based off your tags, and commits) is how pretty much every other project I've worked on does this. I really don't

Re: git gc seems to break --symbolic-full-name

24.07.2017 07:02, Jacob Keller пишет: generally, I'd suggest using "git describe" to output a version based on tag, and as part of your build system set that in some sort of --version output of some kind. I came to the following solution which looks quite simple (avoids comparing the output of

Re: git gc seems to break --symbolic-full-name

24.07.2017 07:02, Jacob Keller пишет: generally, I'd suggest using "git describe" to output a version based on tag, and as part of your build system set that in some sort of --version output of some kind. I am not sure I understand that suggestion. I can use 'git describe' (and that seems to be

Re: git gc seems to break --symbolic-full-name

23.07.2017 11:40, Jacob Keller пишет: On Fri, Jul 21, 2017 at 12:03 PM, Stas Sergeev <s...@list.ru> wrote: I wanted some kind of file to use it as a build dependency for the files that needs to be re-built when the head changes. This works very well besides git gc. What other method can b

Re: git gc seems to break --symbolic-full-name

21.07.2017 21:56, Junio C Hamano пишет: Stas Sergeev <s...@list.ru> writes: I do the following: $ git rev-parse --symbolic-full-name devel refs/heads/devel $ ls -l .git/`git rev-parse --symbolic-full-name devel` -rw-rw-r-- 1 stas stas 41 июл 21 15:05 .git/refs/heads/devel This i

git gc seems to break --symbolic-full-name

Hello. I do the following: $ git rev-parse --symbolic-full-name devel refs/heads/devel $ ls -l .git/`git rev-parse --symbolic-full-name devel` -rw-rw-r-- 1 stas stas 41 июл 21 15:05 .git/refs/heads/devel This is fine. But after git gc: $ git rev-parse --symbolic-full-name devel

[bug #51466] grub ignores gfxpayload=keep

URL: Summary: grub ignores gfxpayload=keep Project: GNU GRUB Submitted by: stsp Submitted on: Fri 14 Jul 2017 04:53:46 PM UTC Category: Terminal Severity: Major

dosemu2 discussions

Hello dosemu users & developers. It looks like dosemu lists are pretty quiet this days, albeit of a bit spamming from linux-kernel development. This is because dosemu1 development have come to an end (AFAIK), and dosemu2 development/discussing all happens within the github platform. There is

Re: [PATCH v7 07/26] x86/insn-eval: Do not BUG on invalid register type

Hi Ricardo, would you mind unsubscribing linux-msdos@ from all your future mails on this subject? Otherwise I am afraid there would be no subscribers left when you are finally done. :) I think all non-kernel-dev MLs should be treated with more care. Eg your initial questions were certainly

Re: Documenting sigaltstack SS_AUTODISRM

24.05.2017 14:09, Michael Kerrisk (man-pages) пишет: One could do this I suppose, but I read POSIX differently from you and, more importantly, SS_ONSTACK breaks portability on numerous other systems and is a no-op on Linux. So, the Linux man page really should warn against its use in the

Re: Documenting sigaltstack SS_AUTODISRM

24.05.2017 14:09, Michael Kerrisk (man-pages) пишет: One could do this I suppose, but I read POSIX differently from you and, more importantly, SS_ONSTACK breaks portability on numerous other systems and is a no-op on Linux. So, the Linux man page really should warn against its use in the

Re: Documenting sigaltstack SS_AUTODISRM

Hello, 24.05.2017 14:09, Michael Kerrisk (man-pages) пишет: Could you please point and cite the spec that says exactly this? I take your point: the text of the spec could be more precise. It does not provide a complete support for my assertion. But, I do think the interpretation I suggest is

Re: Documenting sigaltstack SS_AUTODISRM

Hello, 24.05.2017 14:09, Michael Kerrisk (man-pages) пишет: Could you please point and cite the spec that says exactly this? I take your point: the text of the spec could be more precise. It does not provide a complete support for my assertion. But, I do think the interpretation I suggest is

Re: Documenting sigaltstack SS_AUTODISRM

23.05.2017 15:26, Michael Kerrisk (man-pages) пишет: and posix seems to allow any other value for enable, which can be (on linux) SS_ONSTACK, not only 0. Yes, long ago someone got confused, as I've noted in a recently added BUGS section in the page: But my understanding differs.

Re: Documenting sigaltstack SS_AUTODISRM

23.05.2017 15:26, Michael Kerrisk (man-pages) пишет: and posix seems to allow any other value for enable, which can be (on linux) SS_ONSTACK, not only 0. Yes, long ago someone got confused, as I've noted in a recently added BUGS section in the page: But my understanding differs.

Re: Documenting sigaltstack SS_AUTODISRM

23.05.2017 13:35, Michael Kerrisk (man-pages) пишет: Hello Stas, Hi. :) Because I don't think we broke the existing code, or did we? Probably not, but it seems to me that there is some small possibility that library code that makes use of sigaltstack() to test whether a signal is being

Re: Documenting sigaltstack SS_AUTODISRM

23.05.2017 13:35, Michael Kerrisk (man-pages) пишет: Hello Stas, Hi. :) Because I don't think we broke the existing code, or did we? Probably not, but it seems to me that there is some small possibility that library code that makes use of sigaltstack() to test whether a signal is being

Re: Documenting sigaltstack SS_AUTODISRM

22.05.2017 23:38, Michael Kerrisk (man-pages) пишет: Stas, I have attempted to document the SS_AUTODISARM feature that you added in Linux 4.7. Could you please take a look at the SS_AUTODISARM pieces in the sigaltstack() man page below? There is also one FIXME that I would like help with. It

Re: Documenting sigaltstack SS_AUTODISRM

22.05.2017 23:38, Michael Kerrisk (man-pages) пишет: Stas, I have attempted to document the SS_AUTODISARM feature that you added in Linux 4.7. Could you please take a look at the SS_AUTODISARM pieces in the sigaltstack() man page below? There is also one FIXME that I would like help with. It

Re: [PATCH v3 1/4] x86/vm86/32: Switch to flush_tlb_mm_range() in mark_screen_rdonly()

27.04.2017 19:08, Andy Lutomirski пишет: Those should probably be pgd_none(), not pgd_none_or_clear_bad(). But this whole function is just garbage. It mucks with page protections without even looking up the VMA. What happens if the pages are file-backed? How about chardevs? I'd like to

Re: [PATCH v3 1/4] x86/vm86/32: Switch to flush_tlb_mm_range() in mark_screen_rdonly()

27.04.2017 19:08, Andy Lutomirski пишет: Those should probably be pgd_none(), not pgd_none_or_clear_bad(). But this whole function is just garbage. It mucks with page protections without even looking up the VMA. What happens if the pages are file-backed? How about chardevs? I'd like to

Re: [PATCH v3 1/4] x86/vm86/32: Switch to flush_tlb_mm_range() in mark_screen_rdonly()

27.04.2017 19:08, Andy Lutomirski пишет: Those should probably be pgd_none(), not pgd_none_or_clear_bad(). But this whole function is just garbage. It mucks with page protections without even looking up the VMA. What happens if the pages are file-backed? How about chardevs? I'd like to

Re: [PATCH v3 1/4] x86/vm86/32: Switch to flush_tlb_mm_range() in mark_screen_rdonly()

27.04.2017 19:08, Andy Lutomirski пишет: Those should probably be pgd_none(), not pgd_none_or_clear_bad(). But this whole function is just garbage. It mucks with page protections without even looking up the VMA. What happens if the pages are file-backed? How about chardevs? I'd like to

Re: [SeaBIOS] PCI regions mapping problem

21.04.2017 09:59, Gerd Hoffmann пишет: On Do, 2017-04-20 at 01:18 +0300, Stas Sergeev wrote: Hello. I tried seabios on an emulator (not qemu) and faced the PCI memory regions overlap. After some debugging I came to the conclusion that seabios simply forgets to align the base addresses

[SeaBIOS] PCI regions mapping problem

Hello. I tried seabios on an emulator (not qemu) and faced the PCI memory regions overlap. After some debugging I came to the conclusion that seabios simply forgets to align the base addresses, and as the result, when the device aligns the address down by clearing the "dont care" bits, it can

[bug #49814] vbe does not reset display start

Follow-up Comment #4, bug #49814 (project grub): I think grub restores the display start only when the boot happens in graphics mode. In fact, I wasn't able to reproduce the problem in that case. The bug happens only if grub works in gfx mode but the boot happens in text mode. In this case, when

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

01.04.2017 20:49, H. Peter Anvin пишет: <x...@kernel.org>,linux-ms...@vger.kernel.org,wine-de...@winehq.org From: h...@zytor.com Message-ID: <3fd12652-aa83-4d73-9914-bba089e58...@zytor.com> On April 1, 2017 6:08:43 AM PDT, Stas Sergeev <s...@list.ru> wrote: 30.03.2017 08:14,

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

01.04.2017 20:49, H. Peter Anvin пишет: ,linux-ms...@vger.kernel.org,wine-de...@winehq.org From: h...@zytor.com Message-ID: <3fd12652-aa83-4d73-9914-bba089e58...@zytor.com> On April 1, 2017 6:08:43 AM PDT, Stas Sergeev wrote: 30.03.2017 08:14, Ricardo Neri пишет: You know the

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

04.04.2017 05:05, Ricardo Neri пишет: On Sat, 2017-04-01 at 16:08 +0300, Stas Sergeev wrote: 30.03.2017 08:14, Ricardo Neri пишет: You know the wine's requirements now - they are very small. And dosemu doesn't need anything at all but smsw. And even smsw is very rare. But emulation is still

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

04.04.2017 05:05, Ricardo Neri пишет: On Sat, 2017-04-01 at 16:08 +0300, Stas Sergeev wrote: 30.03.2017 08:14, Ricardo Neri пишет: You know the wine's requirements now - they are very small. And dosemu doesn't need anything at all but smsw. And even smsw is very rare. But emulation is still

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

04.04.2017 05:05, Ricardo Neri пишет: On Sat, 2017-04-01 at 16:08 +0300, Stas Sergeev wrote: 30.03.2017 08:14, Ricardo Neri пишет: You know the wine's requirements now - they are very small. And dosemu doesn't need anything at all but smsw. And even smsw is very rare. But emulation is still

[bug #49814] vbe does not reset display start

Follow-up Comment #3, bug #49814 (project grub): Hi. I am very sorry to not participate here, but the savannah e-mails got spam-blocked. :( So the problem is likely that I am not using the linux loader then? The relevant config part is: --- menuentry 'KOS_64' { recordfail

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

30.03.2017 08:14, Ricardo Neri пишет: You know the wine's requirements now - they are very small. And dosemu doesn't need anything at all but smsw. And even smsw is very rare. But emulation is still needed for SMSW, right? Likely so. If you want, I can enable the logging of this command and

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

30.03.2017 08:14, Ricardo Neri пишет: You know the wine's requirements now - they are very small. And dosemu doesn't need anything at all but smsw. And even smsw is very rare. But emulation is still needed for SMSW, right? Likely so. If you want, I can enable the logging of this command and

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

30.03.2017 08:14, Ricardo Neri пишет: You know the wine's requirements now - they are very small. And dosemu doesn't need anything at all but smsw. And even smsw is very rare. But emulation is still needed for SMSW, right? Likely so. If you want, I can enable the logging of this command and

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

31.03.2017 17:11, Alexandre Julliard пишет: In fact it would be nice to be able to make sidt/sgdt/etc. segfault too. I know a new syscall is a pain, Maybe arch_prctl() then? -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

31.03.2017 17:11, Alexandre Julliard пишет: In fact it would be nice to be able to make sidt/sgdt/etc. segfault too. I know a new syscall is a pain, Maybe arch_prctl() then?

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

31.03.2017 17:11, Alexandre Julliard пишет: In fact it would be nice to be able to make sidt/sgdt/etc. segfault too. I know a new syscall is a pain, Maybe arch_prctl() then?

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

30.03.2017 08:14, Ricardo Neri пишет: But at least dosemu implements it, so probably it is needed. Right. Of course if it is used by one of 100 DOS progs, then there is an option to just add its support to dosemu2 and pretend the compatibility problems did not exist. :) Do you mean relaying

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

30.03.2017 08:14, Ricardo Neri пишет: But at least dosemu implements it, so probably it is needed. Right. Of course if it is used by one of 100 DOS progs, then there is an option to just add its support to dosemu2 and pretend the compatibility problems did not exist. :) Do you mean relaying

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

30.03.2017 08:14, Ricardo Neri пишет: But at least dosemu implements it, so probably it is needed. Right. Of course if it is used by one of 100 DOS progs, then there is an option to just add its support to dosemu2 and pretend the compatibility problems did not exist. :) Do you mean relaying

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

11.03.2017 02:59, Ricardo Neri пишет: On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote: Why would you need one? Or do you really want to allow these instructions in v86 by the means of emulation? If so - this wasn't clearly stated in the patch description, neither it was properly

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

11.03.2017 02:59, Ricardo Neri пишет: On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote: Why would you need one? Or do you really want to allow these instructions in v86 by the means of emulation? If so - this wasn't clearly stated in the patch description, neither it was properly

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

11.03.2017 02:59, Ricardo Neri пишет: On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote: Why would you need one? Or do you really want to allow these instructions in v86 by the means of emulation? If so - this wasn't clearly stated in the patch description, neither it was properly

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

29.03.2017 07:38, Ricardo Neri пишет: Probably you could also remove the sldt and str emulation for protected mode, because, as I understand from this thread, wine does not need those. I see. I would lean on keeping the emulation because I already implemented it :), for completeness, and

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

29.03.2017 07:38, Ricardo Neri пишет: Probably you could also remove the sldt and str emulation for protected mode, because, as I understand from this thread, wine does not need those. I see. I would lean on keeping the emulation because I already implemented it :), for completeness, and

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

29.03.2017 07:38, Ricardo Neri пишет: Probably you could also remove the sldt and str emulation for protected mode, because, as I understand from this thread, wine does not need those. I see. I would lean on keeping the emulation because I already implemented it :), for completeness, and

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

28.03.2017 02:46, Ricardo Neri пишет: On Tue, 2017-03-14 at 00:25 +0300, Stas Sergeev wrote: 11.03.2017 02:59, Ricardo Neri пишет: On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote: Why would you need one? Or do you really want to allow these instructions in v86 by the means of emulation

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

28.03.2017 02:46, Ricardo Neri пишет: On Tue, 2017-03-14 at 00:25 +0300, Stas Sergeev wrote: 11.03.2017 02:59, Ricardo Neri пишет: On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote: Why would you need one? Or do you really want to allow these instructions in v86 by the means of emulation

Re: Problem: net: mvneta: auto-negotiation with disconnected network cable

24.03.2017 17:39, Maxime Morin пишет: I did a "git bisect" to find when the regression was introduced, because it previously worked with kernel 4.4, but not with the recent ones. The commit that made appear the issue is this one:

  1   2   3   4   5   6   7   8   9   10   >