udev 147 (ata_id) blanks RW media

udev 147 (ata_id) blanks RW media

[Christoph Stritt]

Hi,

im forwarding this bug since it is udev ata_id that is causing it:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bugU6635
(i hope its ok to do it this way)

verified myself on debian sid but with custom kernel 2.6.31.2:

udev 146 ata_id:
========

# ./ata_id /dev/hdb
TSSTcorpCD_DVDW_TS-L632B_95RB404055

# ./ata_id --export /dev/hdb
ID_TYPEÍ
ID_BUS=ata
ID_MODEL=TSSTcorpCD_DVDW_TS-L632B
ID_MODEL_ENC=TSSTcorpCD\x2fDVDW\x20TS-L632B
ID_REVISION=TM31
ID_SERIAL=TSSTcorpCD_DVDW_TS-L632B_95RB404055
ID_SERIAL_SHORT•RB404055


udev 147 ata_id:
========

# ./ata_id /dev/hdb

-> rw media gets blanked completely (like wodim -blank=all)
.. which is particularly annoying when you are booting of it ..

Re: udev 147 (ata_id) blanks RW media

[Marco d'Itri]

On Nov 19, Christoph Stritt <phoenix@jobob.com> wrote:

> im forwarding this bug since it is udev ata_id that is causing it:
Again: please try to reproduce the issue after booting with
init=/bin/bash and running ata_id from the command line with no udevd
process running.

-- 
ciao,
Marco

Re: udev 147 (ata_id) blanks RW media

[Christoph Stritt]

Marco d'Itri wrote:

>> im forwarding this bug since it is udev ata_id that is causing it:
> Again: please try to reproduce the issue after booting with
> init=/bin/bash and running ata_id from the command line with no udevd
> process running.
> 

sorry for not mentioning it, but that IS how i tested it.
Well, with init=/bin/sh.

With my old boot disk, kernel 2.6.24.4, it happens aswell.

Re: udev 147 (ata_id) blanks RW media

[Christoph Stritt]

Having a quick look at extras/ata_id.c i'd guess it has to do something with
line 85:

    cdb[0] = 0xa1; /* OPERATION CODE: 12 byte pass through */

since 0xa1 is the command for blanking aswell. Smells fishy.

Re: udev 147 (ata_id) blanks RW media

[Kay Sievers]

On Thu, Nov 19, 2009 at 15:29, Christoph Stritt <phoenix@jobob.com> wrote:
> Marco d'Itri wrote:
>
>>> im forwarding this bug since it is udev ata_id that is causing it:
>> Again: please try to reproduce the issue after booting with
>> init=/bin/bash and running ata_id from the command line with no udevd
>> process running.
>>
>
> sorry for not mentioning it, but that IS how i tested it.
> Well, with init=/bin/sh.
>
> With my old boot disk, kernel 2.6.24.4, it happens aswell.

Hmm, I have a:
  INQUIRY: [TSSTcorp][CDDVDW SE-S084B ][TS01]
here, and it seems not to not kill any RW media.

It's maybe caused by the recently added ATA queries:
  http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;hf094a4a7fc1d303e80785d586800eae9841502b

Any chance to try if the same happens with the current libata drivers
(sr0) instead of the now deprecated IDE drivers (hdb)?

Thanks,
Kay

Re: udev 147 (ata_id) blanks RW media

[Kay Sievers]

On Thu, Nov 19, 2009 at 15:51, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Thu, Nov 19, 2009 at 15:29, Christoph Stritt <phoenix@jobob.com> wrote:
>> Marco d'Itri wrote:
>>
>>>> im forwarding this bug since it is udev ata_id that is causing it:
>>> Again: please try to reproduce the issue after booting with
>>> init=/bin/bash and running ata_id from the command line with no udevd
>>> process running.
>>>
>>
>> sorry for not mentioning it, but that IS how i tested it.
>> Well, with init=/bin/sh.
>>
>> With my old boot disk, kernel 2.6.24.4, it happens aswell.
>
> Hmm, I have a:
>  INQUIRY: [TSSTcorp][CDDVDW SE-S084B ][TS01]
> here, and it seems not to not kill any RW media.
>
> It's maybe caused by the recently added ATA queries:
>  http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;hf094a4a7fc1d303e80785d586800eae9841502b
>
> Any chance to try if the same happens with the current libata drivers
> (sr0) instead of the now deprecated IDE drivers (hdb)?

It would be still interesting to know, if the same happens with the
new drivers. But it would not happen by default, because we do not run
ata_id on optical drives with the libata drivers.

Thanks,
Kay

Re: udev 147 (ata_id) blanks RW media

[Christoph Stritt]

Kay Sievers wrote:
> On Thu, Nov 19, 2009 at 15:51, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> On Thu, Nov 19, 2009 at 15:29, Christoph Stritt <phoenix@jobob.com> wrote:
>>> Marco d'Itri wrote:
>>>
>>>>> im forwarding this bug since it is udev ata_id that is causing it:
>>>> Again: please try to reproduce the issue after booting with
>>>> init=/bin/bash and running ata_id from the command line with no udevd
>>>> process running.
>>>>
>>> sorry for not mentioning it, but that IS how i tested it.
>>> Well, with init=/bin/sh.
>>>
>>> With my old boot disk, kernel 2.6.24.4, it happens aswell.
>> Hmm, I have a:
>>  INQUIRY: [TSSTcorp][CDDVDW SE-S084B ][TS01]
>> here, and it seems not to not kill any RW media.
>>
>> It's maybe caused by the recently added ATA queries:
>>  http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;hf094a4a7fc1d303e80785d586800eae9841502b
>>
>> Any chance to try if the same happens with the current libata drivers
>> (sr0) instead of the now deprecated IDE drivers (hdb)?
> 
> It would be still interesting to know, if the same happens with the
> new drivers. But it would not happen by default, because we do not run
> ata_id on optical drives with the libata drivers.

I changed my Kernel to libata+ata_piix (intel ich6). Only change is that it
doesn't get erased on boot, as you stated.
# ./ata_id /dev/sr0 blanks the disk as it did with the older ata drivers (hdb).

Re: udev 147 (ata_id) blanks RW media

[Kay Sievers]

On Thu, Nov 19, 2009 at 19:03, Christoph Stritt <phoenix@jobob.com> wrote:
> Kay Sievers wrote:
>> On Thu, Nov 19, 2009 at 15:51, Kay Sievers <kay.sievers@vrfy.org> wrote:
>>> On Thu, Nov 19, 2009 at 15:29, Christoph Stritt <phoenix@jobob.com> wrote:
>>>> Marco d'Itri wrote:
>>>>
>>>>>> im forwarding this bug since it is udev ata_id that is causing it:
>>>>> Again: please try to reproduce the issue after booting with
>>>>> init=/bin/bash and running ata_id from the command line with no udevd
>>>>> process running.
>>>>>
>>>> sorry for not mentioning it, but that IS how i tested it.
>>>> Well, with init=/bin/sh.
>>>>
>>>> With my old boot disk, kernel 2.6.24.4, it happens aswell.
>>> Hmm, I have a:
>>>  INQUIRY: [TSSTcorp][CDDVDW SE-S084B ][TS01]
>>> here, and it seems not to not kill any RW media.
>>>
>>> It's maybe caused by the recently added ATA queries:
>>>  http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;hf094a4a7fc1d303e80785d586800eae9841502b
>>>
>>> Any chance to try if the same happens with the current libata drivers
>>> (sr0) instead of the now deprecated IDE drivers (hdb)?
>>
>> It would be still interesting to know, if the same happens with the
>> new drivers. But it would not happen by default, because we do not run
>> ata_id on optical drives with the libata drivers.
>
> I changed my Kernel to libata+ata_piix (intel ich6). Only change is that it
> doesn't get erased on boot, as you stated.
> # ./ata_id /dev/sr0 blanks the disk as it did with the older ata drivers (hdb).

Ok, something to look into. Thanks a lot for the tests!

Kay

Re: udev 147 (ata_id) blanks RW media

[Kay Sievers]

On Thu, Nov 19, 2009 at 19:24, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Thu, Nov 19, 2009 at 19:03, Christoph Stritt <phoenix@jobob.com> wrote:
>> Kay Sievers wrote:
>>> On Thu, Nov 19, 2009 at 15:51, Kay Sievers <kay.sievers@vrfy.org> wrote:
>>>> On Thu, Nov 19, 2009 at 15:29, Christoph Stritt <phoenix@jobob.com> wrote:
>>>>> Marco d'Itri wrote:
>>>>>
>>>>>>> im forwarding this bug since it is udev ata_id that is causing it:
>>>>>> Again: please try to reproduce the issue after booting with
>>>>>> init=/bin/bash and running ata_id from the command line with no udevd
>>>>>> process running.
>>>>>>
>>>>> sorry for not mentioning it, but that IS how i tested it.
>>>>> Well, with init=/bin/sh.
>>>>>
>>>>> With my old boot disk, kernel 2.6.24.4, it happens aswell.
>>>> Hmm, I have a:
>>>>  INQUIRY: [TSSTcorp][CDDVDW SE-S084B ][TS01]
>>>> here, and it seems not to not kill any RW media.
>>>>
>>>> It's maybe caused by the recently added ATA queries:
>>>>  http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;hf094a4a7fc1d303e80785d586800eae9841502b
>>>>
>>>> Any chance to try if the same happens with the current libata drivers
>>>> (sr0) instead of the now deprecated IDE drivers (hdb)?
>>>
>>> It would be still interesting to know, if the same happens with the
>>> new drivers. But it would not happen by default, because we do not run
>>> ata_id on optical drives with the libata drivers.
>>
>> I changed my Kernel to libata+ata_piix (intel ich6). Only change is that it
>> doesn't get erased on boot, as you stated.
>> # ./ata_id /dev/sr0 blanks the disk as it did with the older ata drivers (hdb).
>
> Ok, something to look into. Thanks a lot for the tests!

For now, I've added a check if the device is an optical drive, which
should prevent this from happening.

Thanks,
Kay

Re: udev 147 (ata_id) blanks RW media

[Christoph Stritt]

Hi,

> For now, I've added a check if the device is an optical drive, which
> should prevent this from happening.
good! saving countless bits from beeing eliminated >)

It might be better though, if i may add this proposal, to check the availability
of ata passthrough, e.g. like in sg_sat_identify.

regards
cs

Re: udev 147 (ata_id) blanks RW media

[Lennart Poettering]

On Fri, 20.11.09 11:07, Christoph Stritt (phoenix@jobob.com) wrote:

heya,

> > For now, I've added a check if the device is an optical drive, which
> > should prevent this from happening.
> good! saving countless bits from beeing eliminated >)
> 
> It might be better though, if i may add this proposal, to check the availability
> of ata passthrough, e.g. like in sg_sat_identify.

Unfortunately most ob the USB bridges I know that support SAT don't
support the detection page which can be used to find out whether SAT
is supported.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4