Skip to contentSkip to conversation

New: bad_page crash when writing to OCZ Agility2 120G

Bugme-new Andrew Morton 1 participant 1 message Sep 29, 2010 1 message not in the archive Memory management

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]/

Andrew Morton

author maintainer
#1 lore raw

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 32 lines · On Wed, 29 Sep 2010 19:03:55 GMT [email protected] wrote:

https://bugzilla.kernel.org/show_bug.cgi?id=19312

           Summary: bad_page crash when writing to OCZ Agility2 120G
           Product: Drivers
           Version: 2.5
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Other
        AssignedTo: [email protected]
        ReportedBy: [email protected]
        Regression: No

Created an attachment (id=31932)
--> (https://bugzilla.kernel.org/attachment.cgi?id=31932)
dmesg output after the Oops

I recently installed OCZ Agility2 120G SSD. When i tried to make a FS on it, i got a crash. After further investigation i found that the crash appears only when PAE is enabled. I tried to boot into minimal shell (init=/bin/bash) and was able to reproduce the crash. This is how i reproduce the bug:

dd if=/dev/zero of=/dev/sda bs=256M

after some gigs of data (up to some tens of gigs) are written, i get an Oops as in the attached dmesg log. After some time from the oops, the system locks up (no NumLock as well as no Alt+SysRq stuff seems to work).

Quoted 10 lines

I tried to plug the SSD to another SATA port, swap it with HDDs, but the bug still persists. I tried to replace my nvidia card with s3virge to no avail. I also tried using mem=1024M kernel cmdline to see if it's because of higher memory PCI access, but the bug persists, though it appeared later than before. Also, the bug sometimes doesn't appear on first write pass, but does on second/third.
Ah, yes, the bug still happened after upgrade to 2.6.35.5 kernel. There's no such problem with any of the HDDs. I suspect this may be related to high speed of SSD which might create some race condition, but i'm not sure.

A repeatable crash in __block_write_full_page() in 2.6.34 and 2.6.35.

Does anyone have time to take a look? scripts/decodecode says

All code
========

   0:   89 5c 24 28             mov    %ebx,0x28(%rsp)
   4:   eb 1f                   jmp    0x25
   6:   77 06                   ja     0xe
   8:   3b 74 24 20             cmp    0x20(%rsp),%esi
   c:   76 1d                   jbe    0x2b
   e:   f0 80 23 fd             lock andb $0xfd,(%rbx)
  12:   f0 80 0b 01             lock orb $0x1,(%rbx)
  16:   8b 5b 04                mov    0x4(%rbx),%ebx
  19:   39 5c 24 28             cmp    %ebx,0x28(%rsp)
  1d:   74 70                   je     0x8f
  1f:   83 c6 01                add    $0x1,%esi
  22:   83 d7 00                adc    $0x0,%edi
  25:   3b 7c 24 24             cmp    0x24(%rsp),%edi
  29:   73 db                   jae    0x6
  2b:*  8b 03                   mov    (%rbx),%eax     <-- trapping instruction
  2d:   a8 20                   test   $0x20,%al
  2f:   74 05                   je     0x36
  31:   f6 c4 02                test   $0x2,%ah
  34:   74 e0                   je     0x16
  36:   a8 02                   test   $0x2,%al
  38:   90                      nop    
  39:   74 db                   je     0x16
  3b:   8b 44 24 2c             mov    0x2c(%rsp),%eax
  3f:   3b                      .byte 0x3b

Code starting with the faulting instruction
===========================================

   0:   8b 03                   mov    (%rbx),%eax
   2:   a8 20                   test   $0x20,%al
   4:   74 05                   je     0xb
   6:   f6 c4 02                test   $0x2,%ah
   9:   74 e0                   je     0xffffffffffffffeb
   b:   a8 02                   test   $0x2,%al
   d:   90                      nop    
   e:   74 db                   je     0xffffffffffffffeb
  10:   8b 44 24 2c             mov    0x2c(%rsp),%eax
  14:   3b                      .byte 0x3b

but my attention span ran out. I _think_ the bh ring got corrupted.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>