Re: [PATCH] x86/kconfig/32: Make CONFIG_VM86 default to n and remove EXPERT
Andy Lutomirski kernel.org> writes: > > VM86 is entirely broken if ptrace, syscall auditing, or NOHZ_FULL is > in use. The code is a big undocumented mess, it's a real PITA to > test, and it looks like a big chunk of vm86_32.c is dead code. It > also plays awful games with the entry asm. Don't forget that it also depends on the null page being mapped, which is why MS disabled it in Win8 by default. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/kconfig/32: Make CONFIG_VM86 default to n and remove EXPERT
Andy Lutomirski luto at kernel.org writes: VM86 is entirely broken if ptrace, syscall auditing, or NOHZ_FULL is in use. The code is a big undocumented mess, it's a real PITA to test, and it looks like a big chunk of vm86_32.c is dead code. It also plays awful games with the entry asm. Don't forget that it also depends on the null page being mapped, which is why MS disabled it in Win8 by default. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/3] Early use of boot service memory
>> I think i can go to a date based black list, that removes the manual >> step. System running firmware before certain date assumes we need >> to do the work around. If firmware is newer than that date, we don't >> use the workaround. Blacklist overrides and allows current behavior >> for new firmware that is subsequently found to be broken and for >> which we can't convenience the manufacturer to fix. >> > > No, we can't, at least not for now. We are continually finding new > platforms with the bug. What about now? ot, but this is a fun read: http://download.lenovo.com/ibmdl/pub/pc/pccbbs/thinkcentre_bios/9sjy81usa.txt Notice the reference to "redhat 6.3"! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/3] Early use of boot service memory
I think i can go to a date based black list, that removes the manual step. System running firmware before certain date assumes we need to do the work around. If firmware is newer than that date, we don't use the workaround. Blacklist overrides and allows current behavior for new firmware that is subsequently found to be broken and for which we can't convenience the manufacturer to fix. No, we can't, at least not for now. We are continually finding new platforms with the bug. What about now? ot, but this is a fun read: http://download.lenovo.com/ibmdl/pub/pc/pccbbs/thinkcentre_bios/9sjy81usa.txt Notice the reference to redhat 6.3! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [BUG] x86: reboot doesn't reboot
> I'll contact > the people I know in Dell and see if I can find anyone from the firmware > division who'll actually talk to us. What about now? As a side note, OT, but: http://arstechnica.com/gadgets/2014/04/fast-but-compromised-gigabytes-amd-powered-mini-gaming-pc-reviewed/?comments=1 (notice the Editor's Pick!)-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [BUG] x86: reboot doesn't reboot
I'll contact the people I know in Dell and see if I can find anyone from the firmware division who'll actually talk to us. What about now? As a side note, OT, but: http://arstechnica.com/gadgets/2014/04/fast-but-compromised-gigabytes-amd-powered-mini-gaming-pc-reviewed/?comments=1 (notice the Editor's Pick!)-- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux, UEFI, and Chromebooks (was RE: [PATCH 0/4] EFI 1:1 mapping)
> On Mon, Jun 03, 2013 at 09:35:07AM -0700, James Bottomley wrote: >> On Mon, 2013-06-03 at 17:24 +0100, Matthew Garrett wrote: >>> That seems optimistic. Windows never calls QueryVariableInfo() during >>> boot services, so what makes you think doing so has ever been tested? >> >> It's used by the UEFI shell package ... every system which boots to the >> shell automatically tests this. I know no locked down UEFI system ships >> with a shell but almost every system in test has a Shell in some form, >> so I think its fairly safe to call it from boot services. > > Why do you persist in this belief that all system vendors are going to > have run a shell, let alone any kind of test suite? That runs counter to > everything we've learned about x86 firmware. People verify that it runs > Windows and then ship it. What is frustrating here is that Google decided that x86 Chromebooks should use different firmware, otherwise it would be easier to convince vendor to fix these firmware bugs. Yuhong Bao-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux, UEFI, and Chromebooks (was RE: [PATCH 0/4] EFI 1:1 mapping)
On Mon, Jun 03, 2013 at 09:35:07AM -0700, James Bottomley wrote: On Mon, 2013-06-03 at 17:24 +0100, Matthew Garrett wrote: That seems optimistic. Windows never calls QueryVariableInfo() during boot services, so what makes you think doing so has ever been tested? It's used by the UEFI shell package ... every system which boots to the shell automatically tests this. I know no locked down UEFI system ships with a shell but almost every system in test has a Shell in some form, so I think its fairly safe to call it from boot services. Why do you persist in this belief that all system vendors are going to have run a shell, let alone any kind of test suite? That runs counter to everything we've learned about x86 firmware. People verify that it runs Windows and then ship it. What is frustrating here is that Google decided that x86 Chromebooks should use different firmware, otherwise it would be easier to convince vendor to fix these firmware bugs. Yuhong Bao-- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On EOMA-68 patent licensing...
I read this: http://hardware.slashdot.org/comments.pl?sid=3102545=41270883 "to explain: the patents are there to protect people from physical harm due to the possibility of idiotic companies creating non-interoperable products that could potentially short-circuit things e.g. a lithium battery. if the scope of this project was to sell only 50,000 units maximum, we would not bother with the patents. however, given that the volume of units is expected to reach several million per year, there is no way in hell that we can leave this to "self-policing"." Makes me wonder what would happen if something similar was tried with EFI or ACPI? Yuhong Bao-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On EOMA-68 patent licensing...
I read this: http://hardware.slashdot.org/comments.pl?sid=3102545cid=41270883 to explain: the patents are there to protect people from physical harm due to the possibility of idiotic companies creating non-interoperable products that could potentially short-circuit things e.g. a lithium battery. if the scope of this project was to sell only 50,000 units maximum, we would not bother with the patents. however, given that the volume of units is expected to reach several million per year, there is no way in hell that we can leave this to self-policing. Makes me wonder what would happen if something similar was tried with EFI or ACPI? Yuhong Bao-- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On WfW 3.11 (was RE: Linux 3.11-rc5)
> Sadly, the numerology doesn't quite work out, and while releasing the > final 3.11 today would be a lovely coincidence (Windows 3.11 was > released twenty years ago today), it is not to be. Personally, I don't consider WfW 3.11 all that impressive, especially when it requires a 386 anyway. You can tell that I hate the MS OS/2 2.0 fiasco quite a lot: http://yuhongbao.blogspot.ca/2012/12/about-ms-os2-20-fiasco-px00307-and-dr.html And I didn't mention the CMD640/RZ1000 in this blog article, where basically the two IDE channels was not really independent, leading to data corruption in multitasking OSes. Let's just say that if OS/2 2.x actually replaced DOS/Windows instead of turning into an entire fiasco, these hardware would not likely have shipped with the problems. Yuhong Bao-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On WfW 3.11 (was RE: Linux 3.11-rc5)
Sadly, the numerology doesn't quite work out, and while releasing the final 3.11 today would be a lovely coincidence (Windows 3.11 was released twenty years ago today), it is not to be. Personally, I don't consider WfW 3.11 all that impressive, especially when it requires a 386 anyway. You can tell that I hate the MS OS/2 2.0 fiasco quite a lot: http://yuhongbao.blogspot.ca/2012/12/about-ms-os2-20-fiasco-px00307-and-dr.html And I didn't mention the CMD640/RZ1000 in this blog article, where basically the two IDE channels was not really independent, leading to data corruption in multitasking OSes. Let's just say that if OS/2 2.x actually replaced DOS/Windows instead of turning into an entire fiasco, these hardware would not likely have shipped with the problems. Yuhong Bao-- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: IO regression after ab8fabd46f on x86 kernels with high memory
> We kernel guys have been asking the distros to ship 64-bit kernels even > in their 32-bit distros for many years, but concerns of compat issues > and the desire to deprecate 32-bit userspace seems to have kept that > from happening. And now there is another reason: to call 64-bit EFI runtime services. In retrospect, I would have stuck with 32-bit EFI with 64-bit kernels calling runtime services in compatibility mode, but of course it is too late for that now. Yuhong Bao-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: IO regression after ab8fabd46f on x86 kernels with high memory
We kernel guys have been asking the distros to ship 64-bit kernels even in their 32-bit distros for many years, but concerns of compat issues and the desire to deprecate 32-bit userspace seems to have kept that from happening. And now there is another reason: to call 64-bit EFI runtime services. In retrospect, I would have stuck with 32-bit EFI with 64-bit kernels calling runtime services in compatibility mode, but of course it is too late for that now. Yuhong Bao-- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] mm,x86: limit 32 bit kernel to 12GB memory
> - I don't think it's necessarily "system stability". The problem with > large amounts of highmem ends up being that we end up using up almost > all of the lowmem just to *track* the huge amount of highmem, and then > we have so little lowmem that we suck at performance and have various > random problems. So it's not just "system stability", it's more fluid > than that. FYI 32-bit Windows already limits to 16GB when 3G/1G split is used for a similar reason. (They default to 2G/2G split.) Yuhong Bao-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] mm,x86: limit 32 bit kernel to 12GB memory
- I don't think it's necessarily system stability. The problem with large amounts of highmem ends up being that we end up using up almost all of the lowmem just to *track* the huge amount of highmem, and then we have so little lowmem that we suck at performance and have various random problems. So it's not just system stability, it's more fluid than that. FYI 32-bit Windows already limits to 16GB when 3G/1G split is used for a similar reason. (They default to 2G/2G split.) Yuhong Bao-- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tip:x86/urgent] x86-64, init: Do not set NX bits on non-NX capable hardware
(resending as plaintext) > During early init, we would incorrectly set the NX bit even if the NX > feature was not supported. Instead, only set this bit if NX is > actually available and enabled. We already do very early detection of > the NX bit to enable it in EFER, this simply extends this detection to > the early page table mask. AFAIK the only production x86-64 processor that don't support NX that I know of is the original Nocona D0 stepping. Must more common are the problem of BIOSes disabling the NX feature. Yuhong Bao-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tip:x86/urgent] x86-64, init: Do not set NX bits on non-NX capable hardware
(resending as plaintext) During early init, we would incorrectly set the NX bit even if the NX feature was not supported. Instead, only set this bit if NX is actually available and enabled. We already do very early detection of the NX bit to enable it in EFER, this simply extends this detection to the early page table mask. AFAIK the only production x86-64 processor that don't support NX that I know of is the original Nocona D0 stepping. Must more common are the problem of BIOSes disabling the NX feature. Yuhong Bao-- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: device tree not the answer in the ARM world [was: Re: running Debian on a Cubieboard]
> the economics of market forces don't work that way. > profit-maximising companies are pathologically and *LEGALLY* bound to > enact the articles of incorporation. so you'd need to show them that > it would hurt their profits to continue the way that they are going. I think legally bound is a myth, but that is off-topic for lkml of course. Yuhong Bao-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: device tree not the answer in the ARM world [was: Re: running Debian on a Cubieboard]
> From: yuhongbao_...@hotmail.com > To: l...@lkcl.net; hancock...@gmail.com > CC: david.goodeno...@btconnect.com; debian-...@lists.debian.org; > linux-kernel@vger.kernel.org; arm-netb...@lists.phcomp.co.uk > Subject: RE: device tree not the answer in the ARM world [was: Re: running > Debian on a Cubieboard] > Date: Thu, 9 May 2013 17:56:33 -0700 > > > the economics of market forces don't work that way. > > profit-maximising companies are pathologically and *LEGALLY* bound to > > enact the articles of incorporation. so you'd need to show them that > > it would hurt their profits to continue the way that they are going. > I think legally bound is a myth, but that is off-topic for lkml of course. And obviously it doesn't matter if it is actually required by law if they practically behave that way. Yuhong Bao-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: device tree not the answer in the ARM world [was: Re: running Debian on a Cubieboard]
From: yuhongbao_...@hotmail.com To: l...@lkcl.net; hancock...@gmail.com CC: david.goodeno...@btconnect.com; debian-...@lists.debian.org; linux-kernel@vger.kernel.org; arm-netb...@lists.phcomp.co.uk Subject: RE: device tree not the answer in the ARM world [was: Re: running Debian on a Cubieboard] Date: Thu, 9 May 2013 17:56:33 -0700 the economics of market forces don't work that way. profit-maximising companies are pathologically and *LEGALLY* bound to enact the articles of incorporation. so you'd need to show them that it would hurt their profits to continue the way that they are going. I think legally bound is a myth, but that is off-topic for lkml of course. And obviously it doesn't matter if it is actually required by law if they practically behave that way. Yuhong Bao-- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: device tree not the answer in the ARM world [was: Re: running Debian on a Cubieboard]
the economics of market forces don't work that way. profit-maximising companies are pathologically and *LEGALLY* bound to enact the articles of incorporation. so you'd need to show them that it would hurt their profits to continue the way that they are going. I think legally bound is a myth, but that is off-topic for lkml of course. Yuhong Bao-- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tip:x86/smap] x86-32: Start out eflags and cr4 clean
> + * Specifically, cr4 exists if and only if CPUID exists, > + * which in turn exists if and only if EFLAGS.ID exists. This may be true for *Intel* 486 CPUs as VME was implemented at the same time as CPUID, but I am not sure that it is true for AMD 486 CPUs. Yuhong Bao-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tip:x86/smap] x86-32: Start out eflags and cr4 clean
+ * Specifically, cr4 exists if and only if CPUID exists, + * which in turn exists if and only if EFLAGS.ID exists. This may be true for *Intel* 486 CPUs as VME was implemented at the same time as CPUID, but I am not sure that it is true for AMD 486 CPUs. Yuhong Bao-- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] USB: XHCI: xhci-ring: Remove unused dma address calculation in inc_enq and inc_deq function
> It looks like your mail client attempted to line wrap it. You might > want to use mutt, thunderbird, or maybe even the plain text gmail > interface to resend this. If anyone is using Outlook, see this: https://lkml.org/lkml/2011/1/25/587 Yuhong Bao-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] USB: XHCI: xhci-ring: Remove unused dma address calculation in inc_enq and inc_deq function
It looks like your mail client attempted to line wrap it. You might want to use mutt, thunderbird, or maybe even the plain text gmail interface to resend this. If anyone is using Outlook, see this: https://lkml.org/lkml/2011/1/25/587 Yuhong Bao-- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
