On 7/25/13 11:51 AM, Cristian Rodríguez wrote:

El 25/07/13 10:12, Jeff Mahoney escribió:

...

On 7/24/13 10:08 PM, Cristian Rodríguez wrote:

...

Hi:

Since moving to 3.11rc2 the following happends

This Oops is being tracked here: https://bugzilla.novell.com/show_bug.cgi?id=831374

Thanks ;) I suspect it has to do with concurrency, when you access the youtube homepage there are a lot of small still images competing to be cached on disk, only a few of them actually render before the system becomes unresponsive.

I'm sure it is. I've added a test user on my development node with its home directory on a btrfs file system and can't reproduce this with Chromium yet. I'm reviewing the readahead code, though, since it's different than the regular read path and there might be races interacting with extent_readpages. -Jeff -- Jeff Mahoney SUSE Labs

On 7/25/13 12:31 PM, Cristian Rodríguez wrote:

El 25/07/13 12:27, Jeff Mahoney escribió:

...

I'm sure it is. I've added a test user on my development node with its home directory on a btrfs file system and can't reproduce this with Chromium yet.

Did you toogle "Simple Cache" to "enable" in chrome://flags ? it is not enabled by default.

Yeah, I enabled it manually.

I can reproduce consistently with that setting and chromium-30.0.1567.0-423.1.x86_64 from network:chromium / openSUSE_12.3 repository.

I grabbed the one from Google, but it should be the same. -Jeff -- Jeff Mahoney SUSE Labs

On 7/25/13 12:36 PM, Cristian Rodríguez wrote:

El 25/07/13 12:27, Jeff Mahoney escribió:

...

I'm sure it is. I've added a test user on my development node with its home directory on a btrfs file system and can't reproduce this with Chromium yet. I'm reviewing the readahead code, though, since it's different than the regular read path and there might be races interacting with extent_readpages.

My mount options are "noatime,nobarrier,compress,discard" ...HRMM..now that I think about it, I should not be using "nobarrier" :-P

noatime: effect is in VFS nobarrier: (this is really ok if you have write cache disabled) compress: not enabled, i don't trust it yet discard: not enabled, huge impact on performance during big unlinks Would you be willing to retest without compress? -Jeff -- Jeff Mahoney SUSE Labs

El 25/07/13 12:51, Jeff Mahoney escribió:

Would you be willing to retest without compress?

Ok, I left the /home mount point only with "noatime" , reboot, enabled simple cache again, tried heavy sites (or just youtube) and the issue *cannot* be reproduced again :-S -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

El 25/07/13 13:32, Jeff Mahoney escribió:

What's the flags line of your /proc/cpuinfo say?

The Oops is in memcpy, which is /super/ optimized based on processor capabilities.

-Jeff

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi flexpriority ept vpid -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On 7/25/13 2:03 PM, Jeff Mahoney wrote:

On 7/25/13 1:40 PM, Cristian Rodríguez wrote:

...

El 25/07/13 13:32, Jeff Mahoney escribió:

...

What's the flags line of your /proc/cpuinfo say?

The Oops is in memcpy, which is /super/ optimized based on processor capabilities.

-Jeff

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi flexpriority ept vpid

Ok. You have the rep_good bit but not the erms bit, so that means the memcpy implementation is memcpy_c.

It looks like the source buffer is invalid.

-Jeff

Ok, I've added a BUG_ON to detect whether we're overrunning the index in extent_buffer_page(). Can you test with a kernel with this commit? commit 15eacb944c080a4757ad6634cc1363bd3705cff4 Author: Jeff Mahoney Date: Thu Jul 25 16:55:37 2013 -0400 btrfs: check index in extent_buffer_page. -Jeff -- Jeff Mahoney SUSE Labs

On 7/25/13 9:26 PM, Cristian Rodríguez wrote:

El 25/07/13 16:59, Jeff Mahoney escribió:

...

Can you test with a kernel with this commit?

commit 15eacb944c080a4757ad6634cc1363bd3705cff4 Author: Jeff Mahoney Date: Thu Jul 25 16:55:37 2013 -0400

btrfs: check index in extent_buffer_page.

-Jeff

To which tree was it commited ? (not found in openSUSE kernel-source at least)

Kernel:HEAD -Jeff -- Jeff Mahoney SUSE Labs

On 07/26/2013 02:40 PM, Cristian Rodríguez wrote:

El 26/07/13 08:26, Jeff Mahoney escribió:

Thanks for your time and attention Jeff, but I think I just figured out why this crash misteriously goes away, GCC ICEs on the machine,reboots randomly, or the usb controller sometimes goes apeshit,there is at least one broken memory chip in my desktop. :-| -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org