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 in
the
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:
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 fine.
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
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
On Oct 21, 2012, Borislav Petkov wrote:
On Sat, Oct 20, 2012 at 11:15:17PM +, 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 sure after you
replied with two other
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 the Linux kernel running under
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 other
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 this with arecord?
What chipset are you on? Please provide
On Oct 21, 2012, Borislav Petkov b...@alien8.de wrote:
On Sun, Oct 21, 2012 at 11:59:36AM +, Artem S. Tashkinov wrote:
http://imageshack.us/a/img685/9452/panicz.jpg
list_del corruption. prev-next should be ... but was ...
Btw, this is one of the debug options I told you
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 a
On Oct 22, 2012, Alan Stern st...@rowland.harvard.edu 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:
Hello,
If I remember correctly kernel developers promised not to break user APIs in
the Linux kernel
however in Linux 3.7 a /proc/PID/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.
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
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:
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
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
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
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
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
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_
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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-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
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 performance
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-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
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
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:
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
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 +-
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
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
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
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
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 +-
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
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,
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:
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,
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 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
regards,
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:
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
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],
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:
>>
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
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
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
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
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,
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
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
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
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
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
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
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,
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
>
>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,
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:
regards,
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
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"
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.
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:
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
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
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
> 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 sure a
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
> 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
> >> reprod
>
> 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
> 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
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
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:
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://
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
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 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,
1 - 100 of 126 matches
Mail list logo