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

2012-11-29 Thread Artem S. Tashkinov
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 519

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

2013-02-10 Thread Artem S. Tashkinov
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: ~12

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

2013-02-12 Thread Artem S. Tashkinov
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 >> (ht

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

2013-02-12 Thread Artem S. Tashkinov
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

2013-02-25 Thread Artem S. Tashkinov
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 fur

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

2013-02-26 Thread Artem S. Tashkinov
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

A reliable kernel panic (3.6.2) and system crash when visiting a particular website

2012-10-20 Thread Artem S. Tashkinov
Hello, I'm running vanilla Linux 3.6.2 x86 on top of CentOS 6.3 userspace. Every time when I enter the chat roulette website, right click anywhere and choose "Settings", my PC crashes (with or without NVIDIA drivers running, it happens even when I'm running Vesa). Web browser: google-chrome-s

Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

2012-10-20 Thread Artem S. Tashkinov
On Oct 21, 2012, Borislav Petkov wrote: > Ok, here's what you can try: > > * You say this happens with google chrome. Does it happen if you use > another browser: firefox, etc? > > * Can you build a 64-bit kernel and try the same with it? The 32-bit > userspace should work in compat mode just f

Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

2012-10-20 Thread Artem S. Tashkinov
Hi, I can only reproduce this panic when my USB webcamera is plugged in - when I click settings in Adobe Flash it sends some commands to my USB webcam using, presumably, Video4Linux API calls which cause a kernel hard crash. Your kernel debug features haven't helped at all, even the virtual machi

Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

2012-10-20 Thread Artem S. Tashkinov
You don't get me - I have *no* VirtualBox (or any proprietary) modules running - but I can reproduce this problem using *the same system running under* VirtualBox in Windows 7 64. It's almost definitely either a USB driver bug or video4linux driver bug: I'm CC'ing linux-media and linux-usb maili

Re: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

2012-10-20 Thread Artem S. Tashkinov
> On Oct 21, 2012, Borislav Petkov wrote: > > On Sat, Oct 20, 2012 at 11:15:17PM +0000, Artem S. Tashkinov wrote: > > You don't get me - I have *no* VirtualBox (or any proprietary) modules > > running > > Ok, good. We got that out of the way - I wanted to make s

Re: Re: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

2012-10-21 Thread Artem S. Tashkinov
On Oct 21, 2012, Borislav Petkov wrote: > > On Sun, Oct 21, 2012 at 01:57:21AM +, Artem S. Tashkinov wrote: > > The freeze happens on my *host* Linux PC. For an experiment I decided > > to check if I could reproduce the freeze under a virtual machine - it > > turns out

Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

2012-10-21 Thread Artem S. Tashkinov
On Oct 21, 2012, Daniel Mack wrote: > A hint at least. How did you enable the audio record exactly? Can you > reproduce this with arecord? > > What chipset are you on? Please provide both "lspci -v" and "lsusb -v" > dumps. As I said, I fail to reproduce that issue on any of my machines. All oth

Re: Re: was: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

2012-10-21 Thread Artem S. Tashkinov
> On Oct 21, 2012, Daniel Mack wrote: > > [Cc: alsa-devel] > > On 21.10.2012 14:30, Artem S. Tashkinov wrote: > > On Oct 21, 2012, Daniel Mack wrote: > > > >> A hint at least. How did you enable the audio record exactly? Can you > >> reproduce

Re: Re: Re: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

2012-10-21 Thread Artem S. Tashkinov
> > On Oct 21, 2012, Borislav Petkov wrote: > > On Sun, Oct 21, 2012 at 11:59:36AM +0000, Artem S. Tashkinov wrote: > > http://imageshack.us/a/img685/9452/panicz.jpg > > > > list_del corruption. prev->next should be ... but was ... > > Btw, this is

Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

2012-10-21 Thread Artem S. Tashkinov
> Nice. Could you do that again with the patch applied I sent yo some > hours ago? That patch was of no help - the system has crashed and I couldn't spot relevant messages. I've no idea what it means. Artem -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of

Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

2012-10-22 Thread Artem S. Tashkinov
On Oct 22, 2012, Alan Stern wrote: > A BUG() at these points would crash the machine hard. And where we > came from doesn't matter; what matters is the values in the pointers. OK, here's what the kernel prints with your patch: usb 6.1.4: ep 86 list del corruption prev: e5103b54 e5103a94 e5103

OOM changes in Linux 3.7 lead to udev warnings and total breakage of KDE 3.5.10/TDE

2012-11-12 Thread Artem S. Tashkinov
Hello, If I remember correctly kernel developers promised not to break user APIs in the Linux kernel however in Linux 3.7 a /proc//oom_adj file has been totally removed which makes KDE 3.5.x (and I suppose TDE) unusable as they depend on this file and simply refuse to start in its absence. Als

Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

2012-11-07 Thread Artem S. Tashkinov
On Nov 8, 2012, Takashi Iwai wrote: > How about the patch below? (It's for 3.6, and won't be applied cleanly > to 3.7, but easy to adapt.) This patch fixes my problem, thank you! You can add me as "Tested by". Artem -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" i

A call to revise sockets behaviour

2013-07-29 Thread Artem S. Tashkinov
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 thi

Re: A call to revise sockets behaviour

2013-07-29 Thread Artem S. Tashkinov
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

Re: A call to revise sockets behaviour

2013-07-29 Thread Artem S. Tashkinov
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

Re: A call to revise sockets behaviour

2013-07-29 Thread Artem S. Tashkinov
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: Abysmal HDD/USB write speed after sleep on a UEFI system

2013-05-07 Thread Artem S. Tashkinov
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 perf

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

2013-05-07 Thread Artem S. Tashkinov
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

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

2013-05-08 Thread Artem S. Tashkinov
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

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

2013-05-08 Thread Artem S. Tashkinov
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 >

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

2013-04-26 Thread Artem S. Tashkinov
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 s

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

2013-04-27 Thread Artem S. Tashkinov
> >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 (

Disabling CPU vulnerabilities workarounds

2018-08-23 Thread Artem S. Tashkinov
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, e.

Disabling CPU vulnerabilities workarounds

2018-08-25 Thread Artem S. Tashkinov
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, e.

Re: Disabling CPU vulnerabilities workarounds

2018-08-25 Thread Artem S. Tashkinov
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 of the

Disabling CPU vulnerabilities workarounds (second try)

2018-11-17 Thread Artem S. Tashkinov
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: [PATCH v2] tools/power turbostat: Fix RAPL summary collection on AMD processors

2021-04-20 Thread Artem S. Tashkinov
_PKG; + 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

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

2019-02-06 Thread Artem S. Tashkinov
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

A long standing issue with RAM usage reporting

2021-03-03 Thread Artem S. Tashkinov
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

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

2013-11-08 Thread Artem S. Tashkinov
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

2013-10-30 Thread Artem S. Tashkinov
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 >

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

2013-10-22 Thread Artem S. Tashkinov
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 partiti

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

2013-10-25 Thread Artem S. Tashkinov
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 partiti

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

2013-10-25 Thread Artem S. Tashkinov
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 >> tr

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

2013-10-25 Thread Artem S. Tashkinov
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 abl

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

2013-10-25 Thread Artem S. Tashkinov
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 im

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

2016-04-07 Thread Artem S. Tashkinov
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.

The most insane proposal in regard to the Linux kernel development

2016-04-02 Thread Artem S. Tashkinov
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

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

2019-08-04 Thread Artem S. Tashkinov
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 ever

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

2019-08-05 Thread Artem S. Tashkinov
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,

On the kernel numbering scheme

2018-04-16 Thread Artem S. Tashkinov
18.5-rc7 into 2019.0.0. Best regards, Artem S. Tashkinov

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

2015-12-20 Thread Artem S. Tashkinov
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 off

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

2015-12-20 Thread Artem S. Tashkinov
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 b54ffb7

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

2015-12-20 Thread Artem S. Tashkinov
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 all

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

2015-12-20 Thread Artem S. Tashkinov
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()"

2015-12-20 Thread Artem S. Tashkinov
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()"

2015-12-20 Thread Artem S. Tashkinov
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: rem

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

2015-12-20 Thread Artem S. Tashkinov
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&m=145066119623811&w=2 Artem, I noticed from bugzillar that the hardware is i386, just wondering if PAE is

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

2015-12-20 Thread Artem S. Tashkinov
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()"

2015-12-20 Thread Artem S. Tashkinov
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 perfor

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

2015-12-20 Thread Artem S. Tashkinov
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()"

2015-12-20 Thread Artem S. Tashkinov
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()"

2015-12-21 Thread Artem S. Tashkinov
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()"

2015-12-21 Thread Artem S. Tashkinov
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 +- drivers/ata/libahc

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

2015-12-21 Thread Artem S. Tashkinov
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 +- drivers/ata/libahc

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

2015-12-21 Thread Artem S. Tashkinov
go wrong. 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 --gi

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

2015-12-21 Thread Artem S. Tashkinov
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

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

2020-05-13 Thread Artem S. Tashkinov
> 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 co

Trying to understand General protection fault/hrtimer_active

2017-08-11 Thread Artem S. Tashkinov
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: Deadl