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
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
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
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
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
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
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
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
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
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
> 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
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
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
> 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
>
> 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
> 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
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
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
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
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
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
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
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:
>
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
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
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
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
>
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
>
>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 (
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.
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.
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
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:
_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
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
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
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
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
>
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
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
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
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
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
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.
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
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
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,
18.5-rc7 into 2019.0.0.
Best regards,
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
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
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
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
>
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
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
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
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
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
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
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?
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?
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
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
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
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
> 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
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
66 matches
Mail list logo