Re: [PATCH v2] tools/power turbostat: Fix RAPL summary collection on AMD processors

return do_rapl & (RAPL_PKG | RAPL_AMD_F17H); case IDX_DRAM_ENERGY: return do_rapl & RAPL_DRAM; case IDX_PP0_ENERGY: The patch works for me. Tested-by: Artem S. Tashkinov

A long standing issue with RAM usage reporting

Hello everyone, I'd love to bring kernel developers' attention to this long standing issue: https://bugzilla.kernel.org/show_bug.cgi?id=201675 It would be great if something was done about it because otherwise htop, top and free and numerous other utilities in Linux have to implement hacks and

[PATCH] Kconfig: default to CC_OPTIMIZE_FOR_PERFORMANCE_O3 for gcc >= 10

> GCC 10 appears to have changed -O2 in order to make compilation time faster when using -flto, seemingly at the expense of performance, in particular with regards to how the inliner works. Since -O3 these days shouldn't have the same set of bugs as 10 years ago, this commit defaults new kernel

Re: Let's talk about the elephant in the room - the Linux kernel's inability to gracefully handle low memory pressure

On 8/5/19 9:05 AM, Hillf Danton wrote: On Sun, 4 Aug 2019 09:23:17 + "Artem S. Tashkinov" wrote: Hello, There's this bug which has been bugging many people for many years already and which is reproducible in less than a few minutes under the latest and greatest kernel,

Let's talk about the elephant in the room - the Linux kernel's inability to gracefully handle low memory pressure

Hello, There's this bug which has been bugging many people for many years already and which is reproducible in less than a few minutes under the latest and greatest kernel, 5.2.6. All the kernel parameters are set to defaults. Steps to reproduce: 1) Boot with mem=4G 2) Disable swap to make

On the issue of CPU model-specific registers write protection in UEFI secure boot mode

Hello LKML, Is there a serious reason why CPU MSR is write protected in UEFI secure boot mode in Linux? * In order to even use MSR you have to be root to `modprobe msr`. * In order to read/write from/to MSR you have to be root as /dev/cpu/*/msr is accessible only by root. * CPU registers

Disabling CPU vulnerabilities workarounds (second try)

Hello, I'm resending my last email since the first one didn't draw enough attention despite the gravity of the situation and the issue has been exacerbated by the recent kernel 4.20 changes which incur even a larger performance loss - up to 50% according to the most recent Phoronix testing:

Disabling CPU vulnerabilities workarounds (second try)

Hello, I'm resending my last email since the first one didn't draw enough attention despite the gravity of the situation and the issue has been exacerbated by the recent kernel 4.20 changes which incur even a larger performance loss - up to 50% according to the most recent Phoronix testing:

Re: Disabling CPU vulnerabilities workarounds

On 08/25/2018 06:39 PM, Casey Schaufler wrote: On 8/25/2018 3:42 AM, Artem S. Tashkinov wrote: Hello LKML, As time goes by more and more fixes of Intel/AMD/ARM CPUs vulnerabilities are added to the Linux kernel without a simple way to disable them all in one fell swoop. Many

Re: Disabling CPU vulnerabilities workarounds

On 08/25/2018 06:39 PM, Casey Schaufler wrote: On 8/25/2018 3:42 AM, Artem S. Tashkinov wrote: Hello LKML, As time goes by more and more fixes of Intel/AMD/ARM CPUs vulnerabilities are added to the Linux kernel without a simple way to disable them all in one fell swoop. Many

Disabling CPU vulnerabilities workarounds

Hello LKML, As time goes by more and more fixes of Intel/AMD/ARM CPUs vulnerabilities are added to the Linux kernel without a simple way to disable them all in one fell swoop. Disabling is a good option for strictly confined environments where no 3d party untrusted code is ever to be run,

Disabling CPU vulnerabilities workarounds

Hello LKML, As time goes by more and more fixes of Intel/AMD/ARM CPUs vulnerabilities are added to the Linux kernel without a simple way to disable them all in one fell swoop. Disabling is a good option for strictly confined environments where no 3d party untrusted code is ever to be run,

Disabling CPU vulnerabilities workarounds

Hello LKML, As time goes by more and more fixes of Intel/AMD/ARM CPUs vulnerabilities are added to the Linux kernel without a simple way to disable them all in one fell swoop. Disabling is a good option for strictly confined environments where no 3d party untrusted code is ever to be run,

Disabling CPU vulnerabilities workarounds

Hello LKML, As time goes by more and more fixes of Intel/AMD/ARM CPUs vulnerabilities are added to the Linux kernel without a simple way to disable them all in one fell swoop. Disabling is a good option for strictly confined environments where no 3d party untrusted code is ever to be run,

On the kernel numbering scheme

regards, Artem S. Tashkinov

On the kernel numbering scheme

regards, Artem S. Tashkinov

Trying to understand General protection fault/hrtimer_active

Hello, After stopping mariadb on our database server, the server physically crashed and required a hard reset in order to get back online. Fortunately the system was able to dump the kernel error: Aug 11 09:22:44 mariadb mysqld[1229]: 2017-08-11 9:22:44 140417868658432 [ERROR] mysqld:

Trying to understand General protection fault/hrtimer_active

Hello, After stopping mariadb on our database server, the server physically crashed and required a hard reset in order to get back online. Fortunately the system was able to dump the kernel error: Aug 11 09:22:44 mariadb mysqld[1229]: 2017-08-11 9:22:44 140417868658432 [ERROR] mysqld:

Re: The most insane proposal in regard to the Linux kernel development

On 2016-04-07 01:05, Greg KH wrote: On Sat, Apr 02, 2016 at 05:43:47PM +0500, Artem S. Tashkinov wrote: One very big justification of this proposal is that core Linux development (I'm talking about various subsystems like mm/ ipc/ and interfaces under block/ fs/ security/ sound/ etc. ) has

Re: The most insane proposal in regard to the Linux kernel development

On 2016-04-07 01:05, Greg KH wrote: On Sat, Apr 02, 2016 at 05:43:47PM +0500, Artem S. Tashkinov wrote: One very big justification of this proposal is that core Linux development (I'm talking about various subsystems like mm/ ipc/ and interfaces under block/ fs/ security/ sound/ etc. ) has

The most insane proposal in regard to the Linux kernel development

Hello all, It's not a secret that there are two basic ways of running a Linux distribution on your hardware. Either you use a stable distro which has quite an outdated kernel release which might not support your hardware or you run the most recent stable version but you lose stability and you

The most insane proposal in regard to the Linux kernel development

Hello all, It's not a secret that there are two basic ways of running a Linux distribution on your hardware. Either you use a stable distro which has quite an outdated kernel release which might not support your hardware or you run the most recent stable version but you lose stability and you

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-22 10:55, Kent Overstreet wrote: On Tue, Dec 22, 2015 at 10:52:37AM +0500, Artem S. Tashkinov wrote: On 2015-12-22 10:38, Kent Overstreet wrote: >On Tue, Dec 22, 2015 at 05:26:12AM +, Junichi Nomura wrote: >>On 12/22/15 12:59, Kent Overstreet wrote: >>> reprodu

Re: IO errors after "block: remove bio_get_nr_vecs()"

rong. What do you think of a patch like this? Artem, can you give this patch a try? This patch ostensibly fixes the issue - at least I cannot immediately reproduce it. You can count me in as "Tested-by: Artem S. Tashkinov" -- Jun'ichi Nomura, NEC Corporation diff --git a/block/blk-c

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-22 01:07, Tejun Heo wrote: Hello, Artem. Can you please apply the following patch on top and see whether anything changes? If it does make the issue go away, can you please revert the ".can_queue" part and test again? Thanks. --- drivers/ata/ahci.h|2 +-

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-22 01:07, Tejun Heo wrote: Hello, Artem. Can you please apply the following patch on top and see whether anything changes? If it does make the issue go away, can you please revert the ".can_queue" part and test again? Thanks. --- drivers/ata/ahci.h|2 +-

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-21 10:23, Linus Torvalds wrote: On Sun, Dec 20, 2015 at 8:47 PM, Linus Torvalds wrote: That said, we obviously need to figure out this current problem regardless first.. ... although maybe it *would* be interesting to hear what happens if you just compile a 64-bit kernel instead?

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-22 01:07, Tejun Heo wrote: Hello, Artem. Can you please apply the following patch on top and see whether anything changes? If it does make the issue go away, can you please revert the ".can_queue" part and test again? Thanks. --- drivers/ata/ahci.h|2 +-

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-21 10:23, Linus Torvalds wrote: On Sun, Dec 20, 2015 at 8:47 PM, Linus Torvalds wrote: That said, we obviously need to figure out this current problem regardless first.. ... although maybe it *would* be interesting to hear what happens if you just

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-22 10:55, Kent Overstreet wrote: On Tue, Dec 22, 2015 at 10:52:37AM +0500, Artem S. Tashkinov wrote: On 2015-12-22 10:38, Kent Overstreet wrote: >On Tue, Dec 22, 2015 at 05:26:12AM +, Junichi Nomura wrote: >>On 12/22/15 12:59, Kent Overstreet wrote: >>> reprodu

Re: IO errors after "block: remove bio_get_nr_vecs()"

rong. What do you think of a patch like this? Artem, can you give this patch a try? This patch ostensibly fixes the issue - at least I cannot immediately reproduce it. You can count me in as "Tested-by: Artem S. Tashkinov" -- Jun'ichi Nomura, NEC Corporation diff --git a/block/blk-c

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-22 01:07, Tejun Heo wrote: Hello, Artem. Can you please apply the following patch on top and see whether anything changes? If it does make the issue go away, can you please revert the ".can_queue" part and test again? Thanks. --- drivers/ata/ahci.h|2 +-

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-21 10:23, Linus Torvalds wrote: On Sun, Dec 20, 2015 at 8:47 PM, Linus Torvalds wrote: That said, we obviously need to figure out this current problem regardless first.. ... although maybe it *would* be interesting to hear what happens if you just compile a 64-bit kernel instead?

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-21 11:55, Tejun Heo wrote: Artem, can you please reproduce the issue with the following patch applied and attach the kernel log? Thanks. I've applied this patch on top of vanilla 4.3.3 kernel (without Linus'es revert). Hopefully it's how you intended it to be. Here's the result

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-21 09:32, Linus Torvalds wrote: On Sun, Dec 20, 2015 at 5:50 PM, Artem S. Tashkinov wrote: P.S. I know Linus doesn't condone PAE but I still find it more preferrable than running a mixed environment with almost zero benefit in regard to performance and quite obvious performance

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-21 08:21, Ming Lei wrote: On Mon, Dec 21, 2015 at 10:25 AM, Artem S. Tashkinov wrote: # cat /sys/block/sda/queue/{max_hw_sectors_kb,max_sectors_kb,max_segments,max_segment_size} 32767 32767 168 65536 Looks it is fine, then maybe it is related with BIOVEC_PHYS_MERGEABLE

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-21 07:18, Ming Lei wrote: On Mon, Dec 21, 2015 at 9:50 AM, Artem S. Tashkinov wrote: BTW, I have posted very similar issue in the link: http://marc.info/?l=linux-ide=145066119623811=2 Artem, I noticed from bugzillar that the hardware is i386, just wondering if PAE is enabled

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-21 06:38, Ming Lei wrote: On Mon, Dec 21, 2015 at 1:51 AM, Linus Torvalds wrote: Kent, Jens, Christoph et al, please see this bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109661 where Artem Tashkinov bisected his problems with 4.3 down to commit b54ffb73cadc ("block:

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-21 04:42, Kent Overstreet wrote: On Mon, Dec 21, 2015 at 04:25:12AM +0500, Artem S. Tashkinov wrote: On 2015-12-20 23:18, Christoph Hellwig wrote: >On Sun, Dec 20, 2015 at 09:51:14AM -0800, Linus Torvalds wrote: >>Kent, Jens, Christoph et al, >> please see this bugzill

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-20 23:44, Kent Overstreet wrote: On Sun, Dec 20, 2015 at 07:18:01PM +0100, Christoph Hellwig wrote: On Sun, Dec 20, 2015 at 09:51:14AM -0800, Linus Torvalds wrote: > Kent, Jens, Christoph et al, ie please see this bugzilla: >o > httpps://bugzilla.kernel.org/show_bug.cgi?id=109661

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-20 23:41, Linus Torvalds wrote: On Sun, Dec 20, 2015 at 10:18 AM, Christoph Hellwig wrote: Artem, can you re-check the commits around this series again? I would be extremtly surprised if it's really this particular commit and not one just before it causing the problem - it just

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-20 23:18, Christoph Hellwig wrote: On Sun, Dec 20, 2015 at 09:51:14AM -0800, Linus Torvalds wrote: Kent, Jens, Christoph et al, please see this bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109661 where Artem Tashkinov bisected his problems with 4.3 down to commit

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-20 22:51, Linus Torvalds wrote: Kent, Jens, Christoph et al, please see this bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109661 where Artem Tashkinov bisected his problems with 4.3 down to commit b54ffb73cadc ("block: remove bio_get_nr_vecs()") that you've all signed

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-21 04:42, Kent Overstreet wrote: On Mon, Dec 21, 2015 at 04:25:12AM +0500, Artem S. Tashkinov wrote: On 2015-12-20 23:18, Christoph Hellwig wrote: >On Sun, Dec 20, 2015 at 09:51:14AM -0800, Linus Torvalds wrote: >>Kent, Jens, Christoph et al, >> please see this bugzill

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-20 23:41, Linus Torvalds wrote: On Sun, Dec 20, 2015 at 10:18 AM, Christoph Hellwig wrote: Artem, can you re-check the commits around this series again? I would be extremtly surprised if it's really this particular commit and not one just before it causing the problem - it just

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-21 08:21, Ming Lei wrote: On Mon, Dec 21, 2015 at 10:25 AM, Artem S. Tashkinov wrote: # cat /sys/block/sda/queue/{max_hw_sectors_kb,max_sectors_kb,max_segments,max_segment_size} 32767 32767 168 65536 Looks it is fine, then maybe it is related with BIOVEC_PHYS_MERGEABLE

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-21 09:32, Linus Torvalds wrote: On Sun, Dec 20, 2015 at 5:50 PM, Artem S. Tashkinov wrote: P.S. I know Linus doesn't condone PAE but I still find it more preferrable than running a mixed environment with almost zero benefit in regard to performance and quite obvious performance

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-20 23:44, Kent Overstreet wrote: On Sun, Dec 20, 2015 at 07:18:01PM +0100, Christoph Hellwig wrote: On Sun, Dec 20, 2015 at 09:51:14AM -0800, Linus Torvalds wrote: > Kent, Jens, Christoph et al, ie please see this bugzilla: >o > httpps://bugzilla.kernel.org/show_bug.cgi?id=109661

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-20 22:51, Linus Torvalds wrote: Kent, Jens, Christoph et al, please see this bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109661 where Artem Tashkinov bisected his problems with 4.3 down to commit b54ffb73cadc ("block: remove bio_get_nr_vecs()") that you've all signed

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-20 23:18, Christoph Hellwig wrote: On Sun, Dec 20, 2015 at 09:51:14AM -0800, Linus Torvalds wrote: Kent, Jens, Christoph et al, please see this bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109661 where Artem Tashkinov bisected his problems with 4.3 down to commit

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-21 06:38, Ming Lei wrote: On Mon, Dec 21, 2015 at 1:51 AM, Linus Torvalds wrote: Kent, Jens, Christoph et al, please see this bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109661 where Artem Tashkinov bisected his problems with 4.3 down to commit b54ffb73cadc ("block:

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-21 07:18, Ming Lei wrote: On Mon, Dec 21, 2015 at 9:50 AM, Artem S. Tashkinov wrote: BTW, I have posted very similar issue in the link: http://marc.info/?l=linux-ide=145066119623811=2 Artem, I noticed from bugzillar that the hardware is i386, just wondering if PAE is enabled

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-21 11:55, Tejun Heo wrote: Artem, can you please reproduce the issue with the following patch applied and attach the kernel log? Thanks. I've applied this patch on top of vanilla 4.3.3 kernel (without Linus'es revert). Hopefully it's how you intended it to be. Here's the result

Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-21 10:23, Linus Torvalds wrote: On Sun, Dec 20, 2015 at 8:47 PM, Linus Torvalds wrote: That said, we obviously need to figure out this current problem regardless first.. ... although maybe it *would* be interesting to hear what happens if you just

Not being able to reread the partition table - why is Linux so 90x?

Hello, I wonder why in 2013 I still cannot modify _unused_ partitions on the fly, yeah, the Internet is full of: # hdparm -z /dev/sda /dev/sda: re-reading partition table BLKRRPART failed: Device or resource busy # fdisk (after adding a new partition using unused space on my hdd) ... Command

Not being able to reread the partition table - why is Linux so 90x?

Hello, I wonder why in 2013 I still cannot modify _unused_ partitions on the fly, yeah, the Internet is full of: # hdparm -z /dev/sda /dev/sda: re-reading partition table BLKRRPART failed: Device or resource busy # fdisk (after adding a new partition using unused space on my hdd) ... Command

Re: Disabling in-memory write cache for x86-64 in Linux II

Oct 30, 2013 02:41:01 AM, Jack wrote: On Fri 25-10-13 19:37:53, Ted Tso wrote: >> Sure, although I wonder if it would be worth it calcuate some kind of >> rolling average of the write bandwidth while we are doing writeback, >> so if it turns out we got unlucky with the contents of the first 100MB

Re: Disabling in-memory write cache for x86-64 in Linux II

Oct 30, 2013 02:41:01 AM, Jack wrote: On Fri 25-10-13 19:37:53, Ted Tso wrote: Sure, although I wonder if it would be worth it calcuate some kind of rolling average of the write bandwidth while we are doing writeback, so if it turns out we got unlucky with the contents of the first 100MB of

Re: Disabling in-memory write cache for x86-64 in Linux II

Oct 26, 2013 02:44:07 AM, neil wrote: On Fri, 25 Oct 2013 18:26:23 + (UTC) "Artem S. Tashkinov" >> >> Exactly. And not being able to use applications which show you IO performance >> like Midnight Commander. You might prefer to use "cp -a" but I cannot

Re: Disabling in-memory write cache for x86-64 in Linux II

Oct 25, 2013 05:26:45 PM, david wrote: On Fri, 25 Oct 2013, NeilBrown wrote: > >> >> What exactly is bothering you about this? The amount of memory used or the >> time until data is flushed? > >actually, I think the problem is more the impact of the huge write later on. Exactly. And not being

Re: Disabling in-memory write cache for x86-64 in Linux II

Oct 25, 2013 02:18:50 PM, Linus Torvalds wrote: On Fri, Oct 25, 2013 at 8:25 AM, Artem S. Tashkinov wrote: >> >> On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11 kernel >> built for the i686 (with PAE) and x86-64 architectures. What's really >> troubli

Disabling in-memory write cache for x86-64 in Linux II

Hello! On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11 kernel built for the i686 (with PAE) and x86-64 architectures. What's really troubling me is that the x86-64 kernel has the following problem: When I copy large files to any storage device, be it my HDD with ext4

Disabling in-memory write cache for x86-64 in Linux II

Hello! On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11 kernel built for the i686 (with PAE) and x86-64 architectures. What's really troubling me is that the x86-64 kernel has the following problem: When I copy large files to any storage device, be it my HDD with ext4

Re: Disabling in-memory write cache for x86-64 in Linux II

Oct 25, 2013 02:18:50 PM, Linus Torvalds wrote: On Fri, Oct 25, 2013 at 8:25 AM, Artem S. Tashkinov wrote: On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11 kernel built for the i686 (with PAE) and x86-64 architectures. What's really troubling me is that the x86-64 kernel

Re: Disabling in-memory write cache for x86-64 in Linux II

Oct 25, 2013 05:26:45 PM, david wrote: On Fri, 25 Oct 2013, NeilBrown wrote: What exactly is bothering you about this? The amount of memory used or the time until data is flushed? actually, I think the problem is more the impact of the huge write later on. Exactly. And not being able to use

Re: Disabling in-memory write cache for x86-64 in Linux II

Oct 26, 2013 02:44:07 AM, neil wrote: On Fri, 25 Oct 2013 18:26:23 + (UTC) Artem S. Tashkinov Exactly. And not being able to use applications which show you IO performance like Midnight Commander. You might prefer to use cp -a but I cannot imagine my life without being able to see

Disabling in-memory write cache for x86-64 in Linux 3.11

Hello, On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11 kernel built for the i686 (with PAE) and x86-64 architectures. What's really troubling me is that the x86-64 kernel has the following problem: When I copy large files to any storage device, be it my HDD with ext4

Disabling in-memory write cache for x86-64 in Linux 3.11

Hello, On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11 kernel built for the i686 (with PAE) and x86-64 architectures. What's really troubling me is that the x86-64 kernel has the following problem: When I copy large files to any storage device, be it my HDD with ext4

Re: A call to revise sockets behaviour

Jul 29, 2013 11:43:00 PM, Eric wrote: On Mon, 2013-07-29 at 15:47 +, Artem S. Tashkinov wrote: > >> A wine developer clearly showed that this option simply doesn't work. >> >> http://bugs.winehq.org/show_bug.cgi?id=26031#c21 >> >> Output of strace: >>

Re: A call to revise sockets behaviour

Jul 29, 2013 11:27:00 PM, rick wrote: >> A wine developer clearly showed that this option simply doesn't work. >> >> http://bugs.winehq.org/show_bug.cgi?id=26031#c21 >> >> Output of strace: >> getsockopt(24, SOL_SOCKET, SO_REUSEADDR, [0], [4]) = 0 >> setsockopt(24, SOL_SOCKET, SO_REUSEADDR, [1],

Re: A call to revise sockets behaviour

Jul 29, 2013 09:35:25 PM, Stephen wrote: On Mon, 29 Jul 2013 15:10:34 + (UTC) >"Artem S. Tashkinov" wrote: > >> Hello, >> >> Currently the Linux kernel disallows to start listening on a TCP/UDP socket >> if >> there are open connections against t

A call to revise sockets behaviour

Hello, Currently the Linux kernel disallows to start listening on a TCP/UDP socket if there are open connections against the port, regardless connections status. So even if _all_ you have is some stale (i.e. no longer active connections pending destruction) the kernel will not allow to reuse

A call to revise sockets behaviour

Hello, Currently the Linux kernel disallows to start listening on a TCP/UDP socket if there are open connections against the port, regardless connections status. So even if _all_ you have is some stale (i.e. no longer active connections pending destruction) the kernel will not allow to reuse

Re: A call to revise sockets behaviour

Jul 29, 2013 09:35:25 PM, Stephen wrote: On Mon, 29 Jul 2013 15:10:34 + (UTC) Artem S. Tashkinov wrote: Hello, Currently the Linux kernel disallows to start listening on a TCP/UDP socket if there are open connections against the port, regardless connections status. So even if _all_

Re: A call to revise sockets behaviour

Jul 29, 2013 11:27:00 PM, rick wrote: A wine developer clearly showed that this option simply doesn't work. http://bugs.winehq.org/show_bug.cgi?id=26031#c21 Output of strace: getsockopt(24, SOL_SOCKET, SO_REUSEADDR, [0], [4]) = 0 setsockopt(24, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0

Re: A call to revise sockets behaviour

Jul 29, 2013 11:43:00 PM, Eric wrote: On Mon, 2013-07-29 at 15:47 +, Artem S. Tashkinov wrote: A wine developer clearly showed that this option simply doesn't work. http://bugs.winehq.org/show_bug.cgi?id=26031#c21 Output of strace: getsockopt(24, SOL_SOCKET, SO_REUSEADDR, [0], [4

Re: Abysmal HDD/USB write speed after sleep on a UEFI system

May 8, 2013 04:25:43 AM, Patrik Jakobsson wrote: On Wed, May 8, 2013 at 12:02 AM, Bjorn Helgaas wrote: >> On Tue, May 7, 2013 at 2:48 PM, Patrik Jakobsson wrote: >>> On Tue, May 7, 2013 at 10:20 PM, Bjorn Helgaas wrote: > I'm not sure if reading /proc/mtrr actually reads the registers out of

Re: Abysmal HDD/USB write speed after sleep on a UEFI system

May 8, 2013 04:03:18 AM, Bjorn Helgaas wrote: On Tue, May 7, 2013 at 2:48 PM, Patrik Jakobsson > wrote: >> On Tue, May 7, 2013 at 10:20 PM, Bjorn Helgaas wrote: I'm not sure if reading /proc/mtrr actually reads the registers out of the CPU each time, or whether we just return the

Re: Abysmal HDD/USB write speed after sleep on a UEFI system

May 8, 2013 04:03:18 AM, Bjorn Helgaas wrote: On Tue, May 7, 2013 at 2:48 PM, Patrik Jakobsson wrote: On Tue, May 7, 2013 at 10:20 PM, Bjorn Helgaas wrote: I'm not sure if reading /proc/mtrr actually reads the registers out of the CPU each time, or whether we just return the cached values we

Re: Abysmal HDD/USB write speed after sleep on a UEFI system

May 8, 2013 04:25:43 AM, Patrik Jakobsson wrote: On Wed, May 8, 2013 at 12:02 AM, Bjorn Helgaas wrote: On Tue, May 7, 2013 at 2:48 PM, Patrik Jakobsson wrote: On Tue, May 7, 2013 at 10:20 PM, Bjorn Helgaas wrote: I'm not sure if reading /proc/mtrr actually reads the registers out of the CPU

Re: Abysmal HDD/USB write speed after sleep on a UEFI system

May 7, 2013 10:27:30 PM, Bjorn Helgaas wrote: On Tue, May 7, 2013 at 8:59 AM, Artem S. Tashkinov wrote: >> May 7, 2013 09:25:40 PM,Bjorn Helgaas wrote: >>> [+cc Phillip] >>> >>>> I would suspect that Windows' complaint about the BIOS mucking up th

Re: Abysmal HDD/USB write speed after sleep on a UEFI system

May 7, 2013 09:25:40 PM,Bjorn Helgaas wrote: > [+cc Phillip] > >> I would suspect that Windows' complaint about the BIOS mucking up the MTRRs >> is likely the best hint. Likely Windows is detecting the problem and fixing >> it up on resume, thus it only complains about "reduced resume

Re: Abysmal HDD/USB write speed after sleep on a UEFI system

May 7, 2013 09:25:40 PM,Bjorn Helgaas wrote: [+cc Phillip] I would suspect that Windows' complaint about the BIOS mucking up the MTRRs is likely the best hint. Likely Windows is detecting the problem and fixing it up on resume, thus it only complains about reduced resume performance.

Re: Abysmal HDD/USB write speed after sleep on a UEFI system

May 7, 2013 10:27:30 PM, Bjorn Helgaas wrote: On Tue, May 7, 2013 at 8:59 AM, Artem S. Tashkinov wrote: May 7, 2013 09:25:40 PM,Bjorn Helgaas wrote: [+cc Phillip] I would suspect that Windows' complaint about the BIOS mucking up the MTRRs is likely the best hint. Likely Windows

Re: Abysmal HDD/USB write speed after sleep on a UEFI system

> >Did this problem ever get resolved? > Hello, Unfortunately, no. Out of curiosity I've tried booting kernel 3.9-rc8 in EUFI mode but it exhibits the same problem. Right after the boot: [root@localhost ~]# dd if=/dev/zero of=test bs=64M count=3 3+0 records in 3+0 records out 201326592 bytes

Re: Abysmal HDD/USB write speed after sleep on a UEFI system

Did this problem ever get resolved? Hello, Unfortunately, no. Out of curiosity I've tried booting kernel 3.9-rc8 in EUFI mode but it exhibits the same problem. Right after the boot: [root@localhost ~]# dd if=/dev/zero of=test bs=64M count=3 3+0 records in 3+0 records out 201326592 bytes

CONFIG_X86_INTEL_PSTATE disables CPU frequency transition stats, many governors and other standard features

Hello, Just wanted to let everyone know that CONFIG_X86_INTEL_PSTATE wreaks havoc with the CPU frequency subsystem in the Linux kernel. With this option enabled: 1) All governors except performance and powersave are gone, ondemand userspace, conservative 2) scaling_cur_freq is gone, thus user

CONFIG_X86_INTEL_PSTATE disables CPU frequency transition stats, many governors and other standard features

Hello, Just wanted to let everyone know that CONFIG_X86_INTEL_PSTATE wreaks havoc with the CPU frequency subsystem in the Linux kernel. With this option enabled: 1) All governors except performance and powersave are gone, ondemand userspace, conservative 2) scaling_cur_freq is gone, thus user

Re: Abysmal HDD/USB write speed after sleep on a UEFI system

Feb 27, 2013 12:47:01 AM, Bjorn Helgaas wrote: On Mon, Feb 25, 2013 at 11:35 PM, Artem S. Tashkinov wrote: >> Feb 26, 2013 03:57:52 AM, Bjorn Helgaas wrote: >>> >>>Where are we at with this, Artem? I assume it's still a problem. >>> >> >> Y

Re: Abysmal HDD/USB write speed after sleep on a UEFI system

Feb 27, 2013 12:47:01 AM, Bjorn Helgaas wrote: On Mon, Feb 25, 2013 at 11:35 PM, Artem S. Tashkinov wrote: Feb 26, 2013 03:57:52 AM, Bjorn Helgaas wrote: Where are we at with this, Artem? I assume it's still a problem. Yes, it is, Bjorn. In order to eliminate this problem I switched back

Re: Abysmal HDD/USB write speed after sleep on a UEFI system

Feb 26, 2013 03:57:52 AM, Bjorn Helgaas wrote: > >Where are we at with this, Artem? I assume it's still a problem. > Yes, it is, Bjorn. In order to eliminate this problem I switched back to MBR yesterday, because so far I haven't received any instructions or guidance as to how I can debug it

Re: Abysmal HDD/USB write speed after sleep on a UEFI system

Feb 26, 2013 03:57:52 AM, Bjorn Helgaas wrote: Where are we at with this, Artem? I assume it's still a problem. Yes, it is, Bjorn. In order to eliminate this problem I switched back to MBR yesterday, because so far I haven't received any instructions or guidance as to how I can debug it

Re: Abysmal HDD/USB write speed after sleep on a UEFI system

Feb 13, 2013 01:32:53 AM, Linus Torvalds wrote: On Tue, Feb 12, 2013 at 10:29 AM, Artem S. Tashkinov wrote: >> Feb 12, 2013 11:30:20 PM, Linus Torvalds wrote: >>> >>>A few things to try to pinpoint: >>> >>> (a) Is it *only* write performance that

Re: Abysmal HDD/USB write speed after sleep on a UEFI system

Feb 12, 2013 11:30:20 PM, Linus Torvalds wrote: >On Mon, Feb 11, 2013 at 10:25 PM, Artem S. Tashkinov wrote: >> Hello Linus, >> >> I 've already posted a bug report >> (https://bugzilla.kernel.org/show_bug.cgi?id=53551), >> a message to LKML >> (http://

Re: Abysmal HDD/USB write speed after sleep on a UEFI system

Feb 12, 2013 11:30:20 PM, Linus Torvalds wrote: On Mon, Feb 11, 2013 at 10:25 PM, Artem S. Tashkinov wrote: Hello Linus, I 've already posted a bug report (https://bugzilla.kernel.org/show_bug.cgi?id=53551), a message to LKML (http://lkml.indiana.edu/hypermail/linux/kernel/1302.1/00837

Re: Abysmal HDD/USB write speed after sleep on a UEFI system

Feb 13, 2013 01:32:53 AM, Linus Torvalds wrote: On Tue, Feb 12, 2013 at 10:29 AM, Artem S. Tashkinov wrote: Feb 12, 2013 11:30:20 PM, Linus Torvalds wrote: A few things to try to pinpoint: (a) Is it *only* write performance that suffers, or is it other performance too? Networking (DMA? Perhaps

Abysmal HDD/USB write speed after sleep on a UEFI system

Hello, I have a P8P67 Pro motherboard made by ASUS and recently I decided to switch to EUFI boot. Maybe it's a coincidence or maybe Linux kernel 3.7.6 (vanilla) has some serious bug but after waking up from sleep write performance becomes intolerable. On boot I have: HDD write performance:

Abysmal HDD/USB write speed after sleep on a UEFI system

Hello, I have a P8P67 Pro motherboard made by ASUS and recently I decided to switch to EUFI boot. Maybe it's a coincidence or maybe Linux kernel 3.7.6 (vanilla) has some serious bug but after waking up from sleep write performance becomes intolerable. On boot I have: HDD write performance:

A vague, murky topic of "Buffer I/O error on device sdb6, logical block NNNNNNNNN" and a ext4/VFS oops

Hello, When I was copying a lot of information (tens of gigabytes) from my primary HDD to a secondary HDD I got gazillions of errors like these ones: [19568.964762] EXT4-fs warning (device sdb6): ext4_end_bio:250: I/O error writing to inode 6029369 (offset 8036352 size 524288 starting block

A vague, murky topic of Buffer I/O error on device sdb6, logical block NNNNNNNNN and a ext4/VFS oops

Hello, When I was copying a lot of information (tens of gigabytes) from my primary HDD to a secondary HDD I got gazillions of errors like these ones: [19568.964762] EXT4-fs warning (device sdb6): ext4_end_bio:250: I/O error writing to inode 6029369 (offset 8036352 size 524288 starting block

  1   2   >