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

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

[Andrew Morton]

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


Begin forwarded message:

Date: Fri, 14 Oct 2005 21:50:14 +0200
From: "F. Poncin" <cr27587@chello.be>
To: linux-kernel@vger.kernel.org
Subject: slab error in cache_free_debugcheck(): cache `sgpool-8':


Hello,
I found this in several recent boot logs.

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

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]
 [<c032ca6e>] _spin_lock+0x1c/0x75
 [<f888cb0a>] scsi_softirq+0xc0/0x141 [scsi_mod]
 [<c01252e1>] tasklet_action+0x59/0xbe
 [<c0124f79>] __do_softirq+0x69/0xd5
 [<c0104ceb>] do_softirq+0x57/0x5b
 =======================
 [<c01250c0>] irq_exit+0x42/0x44
 [<c0104bbc>] do_IRQ+0x5c/0x8e
 [<c032b277>] schedule+0x627/0xcd8
 [<c01036a6>] common_interrupt+0x1a/0x20
 [<c0100e91>] mwait_idle+0x25/0x4a
 [<c023d243>] acpi_processor_idle+0x0/0x29e
 [<c023d344>] acpi_processor_idle+0x101/0x29e
 [<c023d243>] acpi_processor_idle+0x0/0x29e
 [<c0100ceb>] cpu_idle+0x45/0x7d
 [<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
 [<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]
 [<c032ca6e>] _spin_lock+0x1c/0x75
 [<f888cb0a>] scsi_softirq+0xc0/0x141 [scsi_mod]
 [<c01252e1>] tasklet_action+0x59/0xbe
 [<c0124f79>] __do_softirq+0x69/0xd5
 [<c0104ceb>] do_softirq+0x57/0x5b
 =======================
 [<c01250c0>] irq_exit+0x42/0x44
 [<c0104bbc>] do_IRQ+0x5c/0x8e
 [<c01036a6>] common_interrupt+0x1a/0x20
 [<c0100e91>] mwait_idle+0x25/0x4a
 [<c023d243>] acpi_processor_idle+0x0/0x29e
 [<c023d344>] acpi_processor_idle+0x101/0x29e
 [<c023d243>] acpi_processor_idle+0x0/0x29e
 [<c0100ceb>] cpu_idle+0x45/0x7d
 [<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
 sdc:<6>FDC 0 is a post-1991 82077


--
Frédéric Poncin

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Stefan Richter]

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/

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

[F. Poncin]

Stefan Richter wrote:

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

No impact on disk access.

>
>> 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)


Brand new Seagate USB/FireWire External Hard Drive - 
http://www.seagate.com/products/personal/external.html
Connected through FireWire to PCI card: FireWire (IEEE 1394): Agere 
Systems (former Lucent Microelectronics) FW323 (rev 61)

The older Seagate model (same size) is not affected.
Vendor: ST340083 Model: 2A Rev:
Type: Direct-Access-RBC ANSI SCSI revision: 04

>
>> 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.

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

[Stefan Richter]

F. Poncin wrote:
> Brand new Seagate USB/FireWire External Hard Drive - 
> http://www.seagate.com/products/personal/external.html
> Connected through FireWire to PCI card: FireWire (IEEE 1394): Agere 
> Systems (former Lucent Microelectronics) FW323 (rev 61)
> 
> The older Seagate model (same size) is not affected.
> Vendor: ST340083 Model: 2A Rev:
> Type: Direct-Access-RBC ANSI SCSI revision: 04
...
>>> 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

I suspect that most of these alleged Direct-Access FireWire bridges are 
actually more or less Direct-Access-RBC bridges. I have two bridges that 
report to be of the Direct-Access type; the Initio based one (although 
1394b/S800, not 1394a like yours) and an older based on TI StorageLynx. 
Both feature different firmware quirks.
-- 
Stefan Richter
-=====-=-=-= =-=- =---=
http://arcgraph.de/sr/

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

[Stefan Richter]

F. Poncin wrote on 2005-10-17:
> Stefan Richter wrote:
>> Andrew Morton wrote:
>>> THis is rather deadly. Is it likely to be a 1394 bug, or scsi?
>>
>> I am not sure.
> 
> No impact on disk access.
> 
>>> 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
...
> Brand new Seagate USB/FireWire External Hard Drive - 
> http://www.seagate.com/products/personal/external.html
> Connected through FireWire to PCI card: FireWire (IEEE 1394): Agere 
> Systems (former Lucent Microelectronics) FW323 (rev 61)
> 
> The older Seagate model (same size) is not affected.
> Vendor: ST340083 Model: 2A Rev:
> Type: Direct-Access-RBC ANSI SCSI revision: 04
...
>>> 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
...
>>> 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
...

Finally there is news for Initio SBP-2 bridges.
http://marc.theaimsgroup.com/?l=linux-scsi&m=114038995826749

Could you try the scsi_mod parameters mentioned there?

Alternatively, update to the latest 1394 drivers (soon to be in -mm, 
curently only at 
http://www.kernel.org/git/?p=linux/kernel/git/scjody/ieee1394.git or 
http://me.in-berlin.de/~s5r6/linux1394/updates/ ) and load sbp2 with 
"modprobe sbp2 force_inquiry_hack=1" before connecting the disk.

If either one of these workarounds helps I would be interested in the 
firmware revision which is logged by sbp2 with force_inquiry_hack=1. You 
can get this value with unpatched drivers too.
-- 
Stefan Richter
-=====-=-==- --=- =-=--
http://arcgraph.de/sr/

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

[F. Poncin]

Stefan Richter wrote:

> F. Poncin wrote on 2005-10-17:
>
>> Stefan Richter wrote:
>>
>>> Andrew Morton wrote:
>>>
>>>> THis is rather deadly. Is it likely to be a 1394 bug, or scsi?
>>>
>>>
>>> I am not sure.
>>
>>
>> No impact on disk access.
>>
>>>> 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
>>>
> ...
>
>> Brand new Seagate USB/FireWire External Hard Drive - 
>> http://www.seagate.com/products/personal/external.html
>> Connected through FireWire to PCI card: FireWire (IEEE 1394): Agere 
>> Systems (former Lucent Microelectronics) FW323 (rev 61)
>>
>> The older Seagate model (same size) is not affected.
>> Vendor: ST340083 Model: 2A Rev:
>> Type: Direct-Access-RBC ANSI SCSI revision: 04
>
> ...
>
>>>> 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
>>>
> ...
>
>>>> 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
>>>
> ...
>
> Finally there is news for Initio SBP-2 bridges.
> http://marc.theaimsgroup.com/?l=linux-scsi&m=114038995826749
>
> Could you try the scsi_mod parameters mentioned there?
>
> Alternatively, update to the latest 1394 drivers (soon to be in -mm, 
> curently only at 
> http://www.kernel.org/git/?p=linux/kernel/git/scjody/ieee1394.git or 
> http://me.in-berlin.de/~s5r6/linux1394/updates/ ) and load sbp2 with 
> "modprobe sbp2 force_inquiry_hack=1" before connecting the disk.
>
> If either one of these workarounds helps I would be interested in the 
> firmware revision which is logged by sbp2 with force_inquiry_hack=1. 
> You can get this value with unpatched drivers too.



On my side, the problem seems to be "solved" since mid-December / 
end-December (linus-git).

latest linus-git:
ieee1394: sbp2: sbp2_firmware_revision = 407

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)
sdc: Write Protect is off
sdc: Mode Sense: 00 13 00 00
sdc: got wrong page
sdc: assuming drive cache: write through
SCSI device sdc: 781422768 512-byte hdwr sectors (400088 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 13 00 00
sdc: got wrong page
sdc: assuming drive cache: write through
sdc: sdc1
sd 8:0:0:0: Attached scsi disk sdc

#echo 8192 > /sys/module/scsi_mod/parameters/default_dev_flags
#modprobe sbp2

ieee1394: Error parsing configrom for node 0-00:1023
=> device not recognised.

#echo "Initio:0KLAT80:8192" > 
/sys/module/scsi_mod/parameters/default_dev_flags
#modprobe sbp2

ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1)
ieee1394: sbp2: Try serialize_io=0 for better performance
scsi9 : SBP-2 IEEE-1394
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)
sdc: Write Protect is off
sdc: Mode Sense: 00 13 00 00
sdc: assuming drive cache: write through
SCSI device sdc: 781422768 512-byte hdwr sectors (400088 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 13 00 00
sdc: assuming drive cache: write through
sdc: sdc1
sd 9:0:0:0: Attached scsi disk sdc

--
Frédéric Poncin
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Stefan Richter]

F. Poncin wrote:
> Stefan Richter wrote:
>> Finally there is news for Initio SBP-2 bridges.
>> http://marc.theaimsgroup.com/?l=linux-scsi&m=114038995826749
>>
>> Could you try the scsi_mod parameters mentioned there?
>>
>> Alternatively, update to the latest 1394 drivers (soon to be in -mm, 
[...]
> On my side, the problem seems to be "solved" since mid-December / 
> end-December (linus-git).

Curious. My 1394b INIC-2430F bridge had the following history:
  - 2.6.13-rc2 panics
  - 2.6.14 works, but why?
  - 2.6.15 panics
I ought to start testing 2.6.16-rc.

> latest linus-git:
> ieee1394: sbp2: sbp2_firmware_revision = 407
> 
> 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)
> sdc: Write Protect is off
> sdc: Mode Sense: 00 13 00 00
> sdc: got wrong page
> sdc: assuming drive cache: write through
> SCSI device sdc: 781422768 512-byte hdwr sectors (400088 MB)
> sdc: Write Protect is off
> sdc: Mode Sense: 00 13 00 00
> sdc: got wrong page
> sdc: assuming drive cache: write through
> sdc: sdc1
> sd 8:0:0:0: Attached scsi disk sdc

Hmm. I wonder if this is just luck.

> #echo 8192 > /sys/module/scsi_mod/parameters/default_dev_flags
> #modprobe sbp2
> 
> ieee1394: Error parsing configrom for node 0-00:1023
> => device not recognised.
> 
> #echo "Initio:0KLAT80:8192" > 
> /sys/module/scsi_mod/parameters/default_dev_flags
> #modprobe sbp2
> 
> ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1)
> ieee1394: sbp2: Try serialize_io=0 for better performance
> scsi9 : SBP-2 IEEE-1394
> 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)
> sdc: Write Protect is off
> sdc: Mode Sense: 00 13 00 00
> sdc: assuming drive cache: write through
> SCSI device sdc: 781422768 512-byte hdwr sectors (400088 MB)
> sdc: Write Protect is off
> sdc: Mode Sense: 00 13 00 00
> sdc: assuming drive cache: write through
> sdc: sdc1
> sd 9:0:0:0: Attached scsi disk sdc

Well, apparently the default_dev_flags syntax does what I intended... :-)

Thanks for testing.
-- 
Stefan Richter
-=====-=-==- --=- =-=--
http://arcgraph.de/sr/