Re: Fw: slab error in cache_free_debugcheck(): cache `sgpool-8':

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Andrew Morton wrote:
THis is rather deadly.   Is it likely to be a 1394 bug, or scsi?

I am not sure.

Begin forwarded message:
...
Summary: slab error in cache_free_debugcheck(): cache `sgpool-8': double free, or memory outside object was overwritten
Kernel version: 2.6.14-rc4-g9149ccfa
Steps to reproduce: on boot
Hardware: Dell 8300 + External USB disk enclosures

(FireWire enclosure, or FireWire attached combo enclosure)

I'm not subscribed to the list. Please Cc:
Additional info / test on request.

extract from dmesg:

scsi2 : SCSI emulation for IEEE-1394 SBP-2 Devices
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
  Vendor: Initio    Model: ST3400832A        Rev: 4.07
  Type:   Direct-Access                      ANSI SCSI revision: 00
SCSI device sdc: 781422768 512-byte hdwr sectors (400088 MB)
slab error in cache_free_debugcheck(): cache `sgpool-8': double free, or memory outside object was overwritten
 [<c014a43b>] cache_free_debugcheck+0x15e/0x215
 [<c0144c73>] mempool_free+0x6c/0x73
 [<c014ae71>] kmem_cache_free+0x25/0x59
 [<c0144c73>] mempool_free+0x6c/0x73
 [<f8891d92>] scsi_io_completion+0x1fd/0x4ac [scsi_mod]
 [<f8826d3f>] sd_rw_intr+0x155/0x30e [sd_mod]
 [<c0148e2b>] poison_obj+0x1c/0x38
 [<c032ca6e>] _spin_lock+0x1c/0x75
 [<f888cc33>] scsi_finish_command+0x82/0xb5 [scsi_mod]
...
 [<c03f088a>] start_kernel+0x18c/0x1cb
 [<c03f030b>] unknown_bootoption+0x0/0x1b0
c233b7a8: redzone 1: 0x170fc2a5, redzone 2: 0xc0144b47.
sdc: asking for cache data failed
sdc: assuming drive cache: write through
SCSI device sdc: 781422768 512-byte hdwr sectors (400088 MB)
slab error in cache_free_debugcheck(): cache `sgpool-8': double free, or memory outside object was overwritten

Note: RBC (reduced block command set) handling, which affects the "asking for cache data" and is applicable to most FireWire harddisks, was moved out of sbp2 into sd_mod (?) some time ago, then temporarily back into sbp2 again due to bugs and incompatibilities of the new RBC handling. We are about to free sbp2 of RBC handling again RSN. (We need to test it more, plus to push the proper patches to -mm for more exposure.)

I have one Initio based 2.5" disk myself which reacted really nasty when the RBC handling changes were introduced. The bridge's firmware seems to be quite quirky. I think the RBC code in sd_mod (?) has become a bit more robust since, but I did not touch that Initio based disk recently. Will test RSN.
--
Stefan Richter
-=====-=-=-= =-=- =---=
http://arcgraph.de/sr/

-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux