On Tue, Mar 16, 2021 at 04:45:02PM +0100, Jiri Olsa wrote:
> hi,
> when running 'perf top' on AMD Rome (/proc/cpuinfo below)
> with fedora 33 kernel 5.10.22-200.fc33.x86_64
>
> we got unknown NMI messages:
>
> [ 226.700160] Uhhuh. NMI received for unknown reason 3d on CPU 90.
> [ 226.700162]
On Sat, Mar 13, 2021 at 11:24:00AM -0500, Neal Gompa wrote:
> On Sat, Mar 13, 2021 at 8:09 AM Adam Borowski wrote:
> >
> > On Wed, Mar 10, 2021 at 02:26:43PM +, Matthew Wilcox wrote:
> > > On Wed, Mar 10, 2021 at 08:21:59AM -0600, Goldwyn Rodrigues wrote:
>
On Wed, Mar 10, 2021 at 02:26:43PM +, Matthew Wilcox wrote:
> On Wed, Mar 10, 2021 at 08:21:59AM -0600, Goldwyn Rodrigues wrote:
> > DAX on btrfs has been attempted[1]. Of course, we could not
>
> But why? A completeness fetish? I don't understand why you decided
> to do this work.
* xfs
On Tue, Mar 09, 2021 at 08:39:10PM +0100, Pavel Machek wrote:
> > I'd like people from Intel to contact me. There's more to fix there,
> > and AFAICT original author went away.
>
> The following message to was
> undeliverable.
> : Recipient
> +address rejected: User unknown in virtual mailbox
On Mon, Feb 08, 2021 at 07:08:05AM +, Wadepohl, Wolfram wrote:
> I'm sad to hear that 5.10 has still an EOL of Dec, 2022. We are in
> development of our 1st GNU/Linux based System, 50k devices for IoT.
[...]
> In general a 2 year support for embedded systems in automation is not a
>
On Mon, Jan 25, 2021 at 11:55:11AM -0800, Scott Branden wrote:
> The 5.10 LTS kernel being officially LTS supported for 2 years presents a
> problem:
> why would anyone select a 5.10 kernel with 2 year LTS when 5.4 kernel has a 6
> year LTS.
>
> Yet, various unofficial reports indicate it will
On Sun, Jan 03, 2021 at 05:45:16PM +, David Laight wrote:
> From: Ilkka Prusi
> > Note that /sbin is now just a symlink to /usr/sbin on Debian since 10
> > (Buster) as per FHS[1][2].
> >
> > [1] https://wiki.linuxfoundation.org/lsb/fhs
> > [2]
> >
On Fri, Dec 04, 2020 at 10:10:16AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Dec 04, 2020 at 09:51:07AM +0100, Jiri Slaby wrote:
> > > > > On Fri, Dec 04, 2020 at 08:22:41AM +0100, Jiri Slaby wrote:
> > > > > > On 03. 12. 20, 3:03, Jann Horn wrote:
> > > > > > > Delete this dead code; but leave
On Fri, Sep 25, 2020 at 11:27:54AM +0200, Greg KH wrote:
> On Thu, Sep 24, 2020 at 08:21:07PM +0200, Thomas Gleixner wrote:
> > On Thu, Sep 24 2020 at 08:33, Greg KH wrote:
> > > On Wed, Sep 23, 2020 at 05:08:32PM -0700, Prasad Sodagudi wrote:
> > >> +config CONSOLE_FLUSH_ON_HOTPLUG
> > >> +
On Wed, Sep 16, 2020 at 10:54:34PM +0200, Pavel Machek wrote:
> On Mon 2020-09-14 18:28:34, Linus Torvalds wrote:
> > Note that scrollback hasn't actually gone away entirely - the original
> > scrollback supported by _hardware_ still exists.
> >
> > Of course, that's really just the old-fashioned
Hi!
My randconfig builds notoriously fail on this:
[~/linux/drivers/scsi/aic7xxx/aicasm](vanilla)$ make -j1
bison -d -b aicasm_gram aicasm_gram.y
mv aicasm_gram.tab.c .//aicasm_gram.c
mv aicasm_gram.tab.h .//aicasm_gram.h
bison -d -b aicasm_macro_gram -p mm aicasm_macro_gram.y
mv
On Fri, Aug 21, 2020 at 10:13:25PM +0200, Thomas Gleixner wrote:
> On Thu, Aug 20 2020 at 14:53, Adam Borowski wrote:
> > Found by randconfig builds.
> >
> > arch/x86/pci/intel_mid_pci.c | 2 ++
> > arch/x86/pci/xen.c | 2 ++
> > --- a/arch/x86/pci/intel
On Tue, Aug 04, 2020 at 09:25:23AM +0200, Sedat Dilek wrote:
> On Tue, Aug 4, 2020 at 8:52 AM Geert Uytterhoeven
> wrote:
> > On Thu, Jul 30, 2020 at 9:13 PM Nick Terrell wrote:
> > > From: Nick Terrell
> > > * Add support for a zstd compressed initramfs.
> > > * Add compression for
On Fri, Jul 24, 2020 at 02:26:40PM +0200, Ingo Molnar wrote:
> > -#ifdef CONFIG_KERNEL_BZIP2
> > +#if defined(CONFIG_KERNEL_BZIP2)
> > # define BOOT_HEAP_SIZE0x40
> > -#else /* !CONFIG_KERNEL_BZIP2 */
> > +#elif defined(CONFIG_KERNEL_ZSTD)
> > +# define BOOT_HEAP_SIZE
On Mon, Jun 08, 2020 at 12:59:44PM +0300, Denis Efremov wrote:
> Redefine GZIP, BZIP2, LZOP variables as KGZIP, KBZIP2, KLZOP resp.
> GZIP, BZIP2, LZOP env variables are reserved by the tools. The original
> attempt to redefine them internally doesn't work in makefiles/scripts
> intercall
On Tue, Apr 28, 2020 at 09:45:27AM +0200, Borislav Petkov wrote:
> On Tue, Apr 21, 2020 at 03:32:34AM +0200, Adam Borowski wrote:
> > Hi!
> > With kernels compiled with gcc-10, on two different machines (AMD Phenom2,
> > AMD 2990WX) I get the following panic during boot:
>
On Thu, Oct 03, 2019 at 10:13:39AM +, David Laight wrote:
> From: Kurt Roeckx
> > Sent: 02 October 2019 17:56
> > As OpenSSL, we want cryptograhic secure random numbers. Before
> > getrandom(), Linux never provided a good API for that, both
> > /dev/random and /dev/urandom have problems.
shutdown meant widespread breakage, but it's no longer
a reasonable filesystem for any non-special use.
Signed-off-by: Adam Borowski
---
Documentation/admin-guide/sysrq.rst | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/Documentation/admin-guide/sysrq.rst
On Thu, Aug 22, 2019 at 10:35:48AM +0200, Borislav Petkov wrote:
> On Thu, Aug 22, 2019 at 02:50:20AM +0200, Adam Borowski wrote:
> > While you're editing that code, could you please also cut the spam if ECC is
> > actually disabled? For example, a 2990WX with non-ECC RAM
On Wed, Aug 21, 2019 at 11:59:53PM +, Ghannam, Yazen wrote:
> I've also added RFC patches to avoid the "ECC disabled" message for
> nodes without memory. I haven't fully tested these, but I wanted to get
> your thoughts. Here's an earlier discussion:
>
On Sat, Aug 03, 2019 at 03:55:37PM +0200, Greg Kroah-Hartman wrote:
> On Sat, Aug 03, 2019 at 03:23:23PM +0200, Adam Borowski wrote:
> > On Fri, Aug 02, 2019 at 09:59:06PM +0200, Paul Menzel wrote:
> > > Because the cable is always connected to the port on the back side, a
On Fri, Aug 02, 2019 at 09:59:06PM +0200, Paul Menzel wrote:
> On 02.08.19 18:02, Greg Kroah-Hartman wrote:
> > On Fri, Aug 02, 2019 at 03:23:08PM +0200, Paul Menzel wrote:
> > > On a lot of devices, like servers, you have more than one serial console,
> > > and you do not always know, how they
On Tue, Jun 25, 2019 at 11:02:36AM +0200, John Paul Adrian Glaubitz wrote:
> On 6/25/19 10:56 AM, Christoph Hellwig wrote:
> > arch/sh seems pretty much unmaintained these days. The last time I got
> > any reply to sh patches from the list maintainers, and the last maintainer
> > pull request was
On Fri, Jun 07, 2019 at 07:20:46PM +, Nick Terrell wrote:
> We'd love to get this mainlined as well!
>
> We're using these patches internally as well. We're seeing an improvement on
> an
> Intel Atom N3710, where boot time is reduced by one second over using an xz
> compressed kernel. It
On Thu, May 16, 2019 at 04:10:07PM +0300, Kirill Tkhai wrote:
> On 15.05.2019 22:38, Adam Borowski wrote:
> > On Wed, May 15, 2019 at 06:11:15PM +0300, Kirill Tkhai wrote:
> >> This patchset adds a new syscall, which makes possible
> >> to clone a mapping from a
On Wed, May 15, 2019 at 06:11:15PM +0300, Kirill Tkhai wrote:
> This patchset adds a new syscall, which makes possible
> to clone a mapping from a process to another process.
> The syscall supplements the functionality provided
> by process_vm_writev() and process_vm_readv() syscalls,
> and it may
On Thu, Apr 25, 2019 at 01:38:06AM +1000, Aleksa Sarai wrote:
> * openat(2) ignores unknown flags, meaning that old kernels will ignore
>new programs trying to use O_THISROOT and might end up causing
>security issues. Yes, it'd be trivial to check whether the new O_*
>flags are
On Thu, Apr 25, 2019 at 11:32:38AM +0200, Nico Schottelius wrote:
> running some IPv6 only
> networks. The systems in the IPv6 only networks do not need any IPv4
> support anymore and thus for switches/routers we turned the support off.
> Today we tried to turn off IPv4 in the Linux kernel at
On Tue, Mar 19, 2019 at 04:31:21PM +, Alan Cox wrote:
> On Sat, 16 Mar 2019 10:35:43 +0100
> Samuel Thibault wrote:
> > Chris Brannon, le ven. 15 mars 2019 18:19:39 -0700, a ecrit:
> > > What kind of reproducer do you need here? It's straightforward to
> > > reproduce in casual use, at least
On Wed, Feb 20, 2019 at 09:20:20PM +0100, Juerg Haefliger wrote:
> On Wed, 20 Feb 2019 14:49:34 -0500
> Steven Rostedt wrote:
>
> > On Wed, 20 Feb 2019 17:13:33 +0100
> > Juerg Haefliger wrote:
> >
> > > echo -e and \e are not POSIX. Depending on what /bin/sh is, we can get
> > > incorrect
On Thu, Jan 24, 2019 at 04:31:10PM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 23.01.19 21:46, Ivan Ivanov wrote:
>
> > Linux really needs to stop adding new features and
> > refactor itself to a smaller and more secure codebase before going
> > forward. Maybe 1 year break would be nice.
Drivers under MIT, BSD-17-clause, or uncle-Bob's-newest-take-on-PD are
all fine, not just GPL.
Signed-off-by: Adam Borowski
---
Not reformatting to fill lines, it'll semi-conflict with another patch
that's been acked but not yet pushed.
Documentation/process/stable-api-nonsense.rst | 3 ++-
1
r patch, no badness happened so far. Thanks!
> Reported-by: Adam Borowski
> Fixes: ac46d4f3c432 ("mm/mmu_notifier: use structure for
> invalidate_range_start/end calls v2")
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> - mmu_notifier_range_init(, vma->vm_mm, vma->vm_s
On Wed, Jan 09, 2019 at 06:38:58AM +0100, Mike Galbraith wrote:
> KVM seems to be busted in master ATM. All I have to do to have host
> start screaming and maybe exploding (if the guest doesn't do so first)
> is to try to install a (obese in this case) kernel over nfs mount of
> the host in a
On Thu, Dec 13, 2018 at 10:37:31AM +0100, Sven Hartrumpf wrote:
> Will the proposed patch ("only") remove the possibility to build x32 kernels
> or will it make impossible to compile and run any x32 binaries?
There's no such thing as x32 kernels. It's an ABI atop amd64 kernels; the
kernel is
On Sun, Nov 11, 2018 at 12:46:35PM +0100, Florian Weimer wrote:
> A lot of multi-threaded applications assume that most high-level
> functionality remains usable even after fork in a multi-threaded
> process.
How would this be even possible? Currently fork kills all threads
(save for the
On Sun, Nov 11, 2018 at 12:46:35PM +0100, Florian Weimer wrote:
> A lot of multi-threaded applications assume that most high-level
> functionality remains usable even after fork in a multi-threaded
> process.
How would this be even possible? Currently fork kills all threads
(save for the
From: Nick Terrell
Add support for extracting ZSTD-compressed kernel images, as well as
ZSTD-compressed ramdisk images in the kernel boot process.
When neither `fill' nor `flush' are used, the decompression function
requires a constant amount of memory (192 KB is sufficient). When either
is
It was really obsolete, and some entries contradicted each other.
Let's not recommend ZSTD for kernel compression yet as it's available
only on x86, and some distros might not have the tool installed.
Proposing ZSTD for initrd is safer but let's test it first.
Signed-off-by: Adam Borowski
From: Nick Terrell
Add support for extracting ZSTD-compressed kernel images, as well as
ZSTD-compressed ramdisk images in the kernel boot process.
When neither `fill' nor `flush' are used, the decompression function
requires a constant amount of memory (192 KB is sufficient). When either
is
It was really obsolete, and some entries contradicted each other.
Let's not recommend ZSTD for kernel compression yet as it's available
only on x86, and some distros might not have the tool installed.
Proposing ZSTD for initrd is safer but let's test it first.
Signed-off-by: Adam Borowski
On Sat, Oct 27, 2018 at 11:13:17AM -0700, Linus Torvalds wrote:
> Ok, so this is a much smaller issue than the i2c one that cause boot
> problems, but it's annoying.
>
> We do *not* enable new random drivers by default. And we most
> *definitely* don't do it when they are odd-ball ones that most
On Sat, Oct 27, 2018 at 11:13:17AM -0700, Linus Torvalds wrote:
> Ok, so this is a much smaller issue than the i2c one that cause boot
> problems, but it's annoying.
>
> We do *not* enable new random drivers by default. And we most
> *definitely* don't do it when they are odd-ball ones that most
Commit-ID: 72a9c673636b779e370983fea08e40f97039b981
Gitweb: https://git.kernel.org/tip/72a9c673636b779e370983fea08e40f97039b981
Author: Adam Borowski
AuthorDate: Tue, 9 Oct 2018 08:28:03 +0200
Committer: Ingo Molnar
CommitDate: Wed, 10 Oct 2018 08:29:51 +0200
x86/defconfig: Enable
Commit-ID: 72a9c673636b779e370983fea08e40f97039b981
Gitweb: https://git.kernel.org/tip/72a9c673636b779e370983fea08e40f97039b981
Author: Adam Borowski
AuthorDate: Tue, 9 Oct 2018 08:28:03 +0200
Committer: Ingo Molnar
CommitDate: Wed, 10 Oct 2018 08:29:51 +0200
x86/defconfig: Enable
On Fri, Sep 28, 2018 at 11:31:32AM +0200, www.Advocati.org wrote:
> CONTRIBUTORS CAN NOT JUST RESCIND THE LICENSE
> THEY GRANTED UNDER GPLv2. IT IS *COPYLEFTED*
> A letter from 17.09.2018 by @observerofaffairs
> titled 'GPL version 2 is a bare license. Recind. (Regarding (future)
> Code of
On Fri, Sep 28, 2018 at 11:31:32AM +0200, www.Advocati.org wrote:
> CONTRIBUTORS CAN NOT JUST RESCIND THE LICENSE
> THEY GRANTED UNDER GPLv2. IT IS *COPYLEFTED*
> A letter from 17.09.2018 by @observerofaffairs
> titled 'GPL version 2 is a bare license. Recind. (Regarding (future)
> Code of
On Tue, Sep 25, 2018 at 11:46:27AM -0400, Theodore Y. Ts'o wrote:
> P.S. One thought: it might be cool if there was some way for
> userspace applications to mark files with "nuke if not closed" flag,
> such that if the system crashes, the file systems would automatically
> unlink the file after a
On Tue, Sep 25, 2018 at 11:46:27AM -0400, Theodore Y. Ts'o wrote:
> P.S. One thought: it might be cool if there was some way for
> userspace applications to mark files with "nuke if not closed" flag,
> such that if the system crashes, the file systems would automatically
> unlink the file after a
On Sun, Sep 16, 2018 at 12:22:43PM -0700, Linus Torvalds wrote:
> This is my reality. I am not an emotionally empathetic kind of person
> and that probably doesn't come as a big surprise to anybody. Least of
> all me. The fact that I then misread people and don't realize (for
> years) how badly
On Sun, Sep 16, 2018 at 12:22:43PM -0700, Linus Torvalds wrote:
> This is my reality. I am not an emotionally empathetic kind of person
> and that probably doesn't come as a big surprise to anybody. Least of
> all me. The fact that I then misread people and don't realize (for
> years) how badly
On Thu, Aug 23, 2018 at 10:43:59AM -0700, Paul E. McKenney wrote:
> The mkinitramfs approach results in about 40MB of initrd, and dracut
> about 10MB. Most of this is completely useless for rcutorture, which
> isn't interested in mounting filesystems, opening devices, and almost
> all of the
On Thu, Aug 23, 2018 at 10:43:59AM -0700, Paul E. McKenney wrote:
> The mkinitramfs approach results in about 40MB of initrd, and dracut
> about 10MB. Most of this is completely useless for rcutorture, which
> isn't interested in mounting filesystems, opening devices, and almost
> all of the
On Sun, Aug 19, 2018 at 04:21:57PM -0700, Linus Torvalds wrote:
> On Sun, Aug 19, 2018 at 3:13 PM Stephen Rothwell
> wrote:
> >
> > Today's linux-next build (powerpc ppc64_defconfig) produced these
> > warnings:
> >
> > fs/cifs/cifssmb.c:605:3: warning: 'strncpy' writing 16 bytes into a region
On Sun, Aug 19, 2018 at 04:21:57PM -0700, Linus Torvalds wrote:
> On Sun, Aug 19, 2018 at 3:13 PM Stephen Rothwell
> wrote:
> >
> > Today's linux-next build (powerpc ppc64_defconfig) produced these
> > warnings:
> >
> > fs/cifs/cifssmb.c:605:3: warning: 'strncpy' writing 16 bytes into a region
On Fri, Aug 17, 2018 at 12:22:44PM -0700, Andi Kleen wrote:
> On Fri, Aug 17, 2018 at 07:57:46PM +0200, Adam Borowski wrote:
> > > The "favourite compressor" seems to roughly change every year, so if
> > > we keep adding new ones things will get more and more
On Fri, Aug 17, 2018 at 12:22:44PM -0700, Andi Kleen wrote:
> On Fri, Aug 17, 2018 at 07:57:46PM +0200, Adam Borowski wrote:
> > > The "favourite compressor" seems to roughly change every year, so if
> > > we keep adding new ones things will get more and more
On Fri, Aug 17, 2018 at 09:54:03AM -0700, Andi Kleen wrote:
> On Fri, Aug 17, 2018 at 06:15:45PM +0200, René Rebe wrote:
> > Hey,
> >
> > is there any mainline future for this zstd support?
> > Currently my most favourite compressor for this, and for what it’s worth
> > zstd/initrd now even
On Fri, Aug 17, 2018 at 09:54:03AM -0700, Andi Kleen wrote:
> On Fri, Aug 17, 2018 at 06:15:45PM +0200, René Rebe wrote:
> > Hey,
> >
> > is there any mainline future for this zstd support?
> > Currently my most favourite compressor for this, and for what it’s worth
> > zstd/initrd now even
On Thu, Aug 16, 2018 at 05:11:21PM +0200, Greg KH wrote:
> On Thu, Aug 16, 2018 at 03:59:58PM +0200, Sven Joachim wrote:
> > On 2018-08-16 15:05 +0200, Adam Borowski wrote:
> > > I'm afraid that I get a build failure; v4.18 is ok, v4.18.1 fails with:
> > >
> > >
On Thu, Aug 16, 2018 at 05:11:21PM +0200, Greg KH wrote:
> On Thu, Aug 16, 2018 at 03:59:58PM +0200, Sven Joachim wrote:
> > On 2018-08-16 15:05 +0200, Adam Borowski wrote:
> > > I'm afraid that I get a build failure; v4.18 is ok, v4.18.1 fails with:
> > >
> > >
Hi!
On Thu, Aug 16, 2018 at 12:14:29PM +0200, Greg KH wrote:
> I'm announcing the release of the 4.18.1 kernel.
I'm afraid that I get a build failure; v4.18 is ok, v4.18.1 fails with:
ld: arch/x86/kvm/x86.o: in function `kvm_get_arch_capabilities':
(.text+0x43b2): undefined reference to
Hi!
On Thu, Aug 16, 2018 at 12:14:29PM +0200, Greg KH wrote:
> I'm announcing the release of the 4.18.1 kernel.
I'm afraid that I get a build failure; v4.18 is ok, v4.18.1 fails with:
ld: arch/x86/kvm/x86.o: in function `kvm_get_arch_capabilities':
(.text+0x43b2): undefined reference to
On Wed, Aug 01, 2018 at 11:36:23AM -0700, Nick Desaulniers wrote:
> It seems that get_maintainer.pl will make recommendations based on
> commit history to a file, but over time, people change emails that
> they commit from, then get_maintainer.pl recommends the possibly now
> invalid email
On Wed, Aug 01, 2018 at 11:36:23AM -0700, Nick Desaulniers wrote:
> It seems that get_maintainer.pl will make recommendations based on
> commit history to a file, but over time, people change emails that
> they commit from, then get_maintainer.pl recommends the possibly now
> invalid email
On Mon, Jul 23, 2018 at 10:53:29AM +0200, Geert Uytterhoeven wrote:
> On Sat, Jul 21, 2018 at 11:39 PM Adam Borowski wrote:
> > Technically, every console can be made to blink by drawing/clearing affected
> > characters a few times per second, but that'd be quite a waste of
On Mon, Jul 23, 2018 at 10:53:29AM +0200, Geert Uytterhoeven wrote:
> On Sat, Jul 21, 2018 at 11:39 PM Adam Borowski wrote:
> > Technically, every console can be made to blink by drawing/clearing affected
> > characters a few times per second, but that'd be quite a waste of
On Sat, Jul 21, 2018 at 09:43:19AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 18, 2018 at 05:01:52AM +0200, Adam Borowski wrote:
> > Here's a patchset with two entangled improvements:
> >
> > * it'd be good to get rid of blinking where possible. Even CGA (thus VGA)
&
On Sat, Jul 21, 2018 at 09:43:19AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 18, 2018 at 05:01:52AM +0200, Adam Borowski wrote:
> > Here's a patchset with two entangled improvements:
> >
> > * it'd be good to get rid of blinking where possible. Even CGA (thus VGA)
&
On Thu, Jul 19, 2018 at 11:47:49AM +0100, Alan Cox wrote:
> On Wed, 18 Jul 2018 05:01:52 +0200
> Adam Borowski wrote:
>
> > Hi!
> > Here's a patchset with two entangled improvements:
> >
> > * it'd be good to get rid of blinking where possible. Even CGA
On Thu, Jul 19, 2018 at 11:47:49AM +0100, Alan Cox wrote:
> On Wed, 18 Jul 2018 05:01:52 +0200
> Adam Borowski wrote:
>
> > Hi!
> > Here's a patchset with two entangled improvements:
> >
> > * it'd be good to get rid of blinking where possible. Even CGA
Let's keep \e[5m setting this bit, it's a nice way to convey the
information, and it preserves old behaviour. Some other terminals
that can't or don't want to blink do so as well.
Signed-off-by: Adam Borowski
---
drivers/tty/vt/vt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers
Let's keep \e[5m setting this bit, it's a nice way to convey the
information, and it preserves old behaviour. Some other terminals
that can't or don't want to blink do so as well.
Signed-off-by: Adam Borowski
---
drivers/tty/vt/vt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers
Hasn't been ever used within historic (ie, git) times.
Signed-off-by: Adam Borowski
---
include/linux/console_struct.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/console_struct.h b/include/linux/console_struct.h
index 2c8d3239899b..fea64f2692a0 100644
: newport looks like it shows bright bg, sti can't do
either, mda appears to blink, etc -- but confirmation would be needed.
Signed-off-by: Adam Borowski
---
drivers/tty/vt/vt.c | 1 +
drivers/video/fbdev/core/fbcon.c | 1 +
include/linux/console_struct.h | 1 +
3 files changed, 3
, thus
there are some differences, among others:
* values very close to black go to 0 (black) rather than 8 (dark grey)
* grayscale ramp is more even
A comparison of the old vs new vs FreeBSD's teken is at:
https://github.com/kilobyte/colorkernel
Signed-off-by: Adam Borowski
---
drivers/tty/vt/vt.c
into only 16
values, but recently 24-bit codes turned from an oddity to something
widespread, thus it's better to handle 256 vs 24-bit consistently.
Signed-off-by: Adam Borowski
---
drivers/tty/vt/vt.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/vt/vt.c
for dark and better for bright inputs.
Signed-off-by: Adam Borowski
---
drivers/tty/vt/vt.c | 38 +-
1 file changed, 17 insertions(+), 21 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index c777f4c91df0..7fcb0ff2dccf 100644
--- a/drivers/tty
Hasn't been ever used within historic (ie, git) times.
Signed-off-by: Adam Borowski
---
include/linux/console_struct.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/console_struct.h b/include/linux/console_struct.h
index 2c8d3239899b..fea64f2692a0 100644
: newport looks like it shows bright bg, sti can't do
either, mda appears to blink, etc -- but confirmation would be needed.
Signed-off-by: Adam Borowski
---
drivers/tty/vt/vt.c | 1 +
drivers/video/fbdev/core/fbcon.c | 1 +
include/linux/console_struct.h | 1 +
3 files changed, 3
, thus
there are some differences, among others:
* values very close to black go to 0 (black) rather than 8 (dark grey)
* grayscale ramp is more even
A comparison of the old vs new vs FreeBSD's teken is at:
https://github.com/kilobyte/colorkernel
Signed-off-by: Adam Borowski
---
drivers/tty/vt/vt.c
into only 16
values, but recently 24-bit codes turned from an oddity to something
widespread, thus it's better to handle 256 vs 24-bit consistently.
Signed-off-by: Adam Borowski
---
drivers/tty/vt/vt.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/vt/vt.c
for dark and better for bright inputs.
Signed-off-by: Adam Borowski
---
drivers/tty/vt/vt.c | 38 +-
1 file changed, 17 insertions(+), 21 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index c777f4c91df0..7fcb0ff2dccf 100644
--- a/drivers/tty
Hi!
Here's a patchset with two entangled improvements:
* it'd be good to get rid of blinking where possible. Even CGA (thus VGA)
allows disabling it, rendering such characters with a bright background
instead.
* due to my error, 256-color mode uses a much darker palette for conversion,
Hi!
Here's a patchset with two entangled improvements:
* it'd be good to get rid of blinking where possible. Even CGA (thus VGA)
allows disabling it, rendering such characters with a bright background
instead.
* due to my error, 256-color mode uses a much darker palette for conversion,
.
Signed-off-by: Adam Borowski
---
drivers/tty/vt/selection.c | 11 +++
drivers/tty/vt/vt.c| 10 ++
include/linux/selection.h | 1 +
3 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/vt/selection.c b/drivers/tty/vt/selection.c
index 69ca337d3220
.
Signed-off-by: Adam Borowski
---
drivers/tty/vt/selection.c | 11 +++
drivers/tty/vt/vt.c| 10 ++
include/linux/selection.h | 1 +
3 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/vt/selection.c b/drivers/tty/vt/selection.c
index 69ca337d3220
Those above U+10 get replaced with U+FFFD.
Signed-off-by: Adam Borowski
---
drivers/tty/vt/selection.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/vt/selection.c b/drivers/tty/vt/selection.c
index 34e7110f310d..69ca337d3220 100644
All the helper function saved us was a cast.
Signed-off-by: Adam Borowski
---
drivers/tty/vt/selection.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/vt/selection.c b/drivers/tty/vt/selection.c
index 90ea1cc52b7a..34e7110f310d 100644
Those above U+10 get replaced with U+FFFD.
Signed-off-by: Adam Borowski
---
drivers/tty/vt/selection.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/vt/selection.c b/drivers/tty/vt/selection.c
index 34e7110f310d..69ca337d3220 100644
All the helper function saved us was a cast.
Signed-off-by: Adam Borowski
---
drivers/tty/vt/selection.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/vt/selection.c b/drivers/tty/vt/selection.c
index 90ea1cc52b7a..34e7110f310d 100644
Hi!
Based on Nicolas' nice work (in tty-next), let's avoid corrupting characters
that have been copy+pasted via mouse selection. The uniscr array holds
their original identity even if they got mangled by glyph conversion.
The glyph conversion lossily turns similar-looking characters into a
Hi!
Based on Nicolas' nice work (in tty-next), let's avoid corrupting characters
that have been copy+pasted via mouse selection. The uniscr array holds
their original identity even if they got mangled by glyph conversion.
The glyph conversion lossily turns similar-looking characters into a
On Tue, Jul 17, 2018 at 09:02:40PM -0400, Nicolas Pitre wrote:
> The nr argument is typically small: most often nr == 1. However this
> could be abused with a very large explicit scroll in a resized screen.
> Make the code scroll lines one at a time in all cases to avoid the VLA.
> Anything
On Tue, Jul 17, 2018 at 09:02:40PM -0400, Nicolas Pitre wrote:
> The nr argument is typically small: most often nr == 1. However this
> could be abused with a very large explicit scroll in a resized screen.
> Make the code scroll lines one at a time in all cases to avoid the VLA.
> Anything
For now, that's arch/x86/boot/compressed/vmlinux.bin.zst but probably more
will come, thus let's be consistent with all other compressors.
Signed-off-by: Adam Borowski
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 97ba6b79834c..0d09cf1c053c
For now, that's arch/x86/boot/compressed/vmlinux.bin.zst but probably more
will come, thus let's be consistent with all other compressors.
Signed-off-by: Adam Borowski
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 97ba6b79834c..0d09cf1c053c
On Wed, Jul 11, 2018 at 01:39:56PM -0700, Kees Cook wrote:
> On Wed, Jul 11, 2018 at 2:18 AM, Greg Kroah-Hartman
> wrote:
> > On Tue, Jul 10, 2018 at 05:52:01PM -0700, Kees Cook wrote:
> >> On Tue, Jun 26, 2018 at 8:56 PM, Nicolas Pitre
> >> wrote:
> >> > +++ b/drivers/tty/vt/vt.c
> >> > [...]
On Wed, Jul 11, 2018 at 01:39:56PM -0700, Kees Cook wrote:
> On Wed, Jul 11, 2018 at 2:18 AM, Greg Kroah-Hartman
> wrote:
> > On Tue, Jul 10, 2018 at 05:52:01PM -0700, Kees Cook wrote:
> >> On Tue, Jun 26, 2018 at 8:56 PM, Nicolas Pitre
> >> wrote:
> >> > +++ b/drivers/tty/vt/vt.c
> >> > [...]
Note that the LZ4 signature is different than that of modern LZ4 as we
use the "legacy" format which suffers from some downsides like inability
to disable compression.
Signed-off-by: Adam Borowski
---
The first time this was sent I managed to screw up both the subject and
scissors lin
1 - 100 of 409 matches
Mail list logo
