Bug 18459 - ahci: sata resets breaks raid
Summary: ahci: sata resets breaks raid
Status: CLOSED NOTABUG
Alias: None
Product: Sisyphus
Classification: Development
Component: kernel-image-std-def (show other bugs)
Version: unstable
Hardware: all Linux
: P2 normal
Assignee: Vitaly Chikunov
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-08 20:14 MSK by Sergey Bolshakov
Modified: 2009-03-22 14:08 MSK (History)
5 users (show)

See Also:


Attachments
sb600 on 2.6.25 (6.86 KB, text/plain)
2009-01-09 17:30 MSK, Sergey Bolshakov
no flags Details
sb600 on 2.6.27 (8.51 KB, text/plain)
2009-01-09 17:31 MSK, Sergey Bolshakov
no flags Details
mcp67 on 2.6.27 (12.32 KB, text/plain)
2009-01-09 17:32 MSK, Sergey Bolshakov
no flags Details
smart data from sdb, mcp67 (4.60 KB, text/plain)
2009-01-09 18:02 MSK, Sergey Bolshakov
no flags Details
smart data from sdc, mcp67 (4.60 KB, text/plain)
2009-01-09 18:03 MSK, Sergey Bolshakov
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey Bolshakov 2009-01-08 20:14:40 MSK
2.6.27-std-def-alt8, матплата на чипсете ATI SB600.
soft-reset sata-линка выбивает соответствующий диск из рейда (md, raid5)
--- %< ---
Jan  7 18:26:57 ns kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Jan  7 18:26:57 ns kernel: ata2.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
Jan  7 18:26:57 ns kernel:          res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Jan  7 18:26:57 ns kernel: ata2.00: status: { DRDY }
Jan  7 18:26:57 ns kernel: ata2: hard resetting link
Jan  7 18:26:57 ns kernel: ata2: softreset failed (device not ready)
Jan  7 18:26:57 ns kernel: ata2: failed due to HW bug, retry pmp=0
Jan  7 18:26:57 ns kernel: ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jan  7 18:26:57 ns kernel: ata2.00: SB600 AHCI: limiting to 255 sectors per cmd
Jan  7 18:26:57 ns kernel: ata2.00: SB600 AHCI: limiting to 255 sectors per cmd
Jan  7 18:26:57 ns mdmonitor: Fail event on /dev/md1, related to disc /dev/sdb3
--- %< ---
вот таким вот весёлым образом за двадцать минут у меня из рэйда вылетели два из трёх блина, с понятными последствиями.
устойчиво повторяется как на alt7 из 5.0 (собственно, на нём и словил), так и на сизифном alt8, с SB600 и на материнке с MCP67 от нвидии.

откатился обратно на 2.6.25-std-def-alt8.M41.4 -- там этой проблемы нет.
Comment 1 Sergey Vlasov 2009-01-09 11:44:40 MSK
А что там за диски? Покажите полностью сообщения из dmesg, начиная с инициализации libata.

На старом ядре нет и самих ошибок, или есть, но обрабатываются без выбрасывания дисков из массива?
Comment 2 Sergey Bolshakov 2009-01-09 17:30:28 MSK
Created attachment 3196 [details]
sb600 on 2.6.25
Comment 3 Sergey Bolshakov 2009-01-09 17:31:03 MSK
Created attachment 3197 [details]
sb600 on 2.6.27
Comment 4 Sergey Bolshakov 2009-01-09 17:32:11 MSK
Created attachment 3198 [details]
mcp67 on 2.6.27
Comment 5 Sergey Bolshakov 2009-01-09 17:33:25 MSK
ошибки есть во всех случаях, но на .25 обрабатываются без вываливания из рэйда
Comment 6 Sergey Bolshakov 2009-01-09 18:02:56 MSK
Created attachment 3199 [details]
smart data from sdb, mcp67
Comment 7 Sergey Bolshakov 2009-01-09 18:03:29 MSK
Created attachment 3200 [details]
smart data from sdc, mcp67
Comment 8 Sergey Vlasov 2009-01-10 17:58:48 MSK
Все ошибки - таймаут команды 0xea (ATA_CMD_FLUSH_EXT - очистка кеша отложенной записи); эта команда используется, в частности, при обработке запросов с флагом BIO_RW_BARRIER. Хотя модуль raid5 не поддерживает такие запросы для самого устройства md, он формирует их для компонентов массива при записи суперблоков, чтобы обеспечить правильный порядок записи (сначала завершаются все отложенные записи, потом записывается суперблок, потом ещё раз выполняется очистка кеша для обеспечения записи данных суперблока на диск).

Похоже, в ядрах до 2.6.26 ошибки при обработке SYNCHRONIZE_CACHE (команда SCSI, которая в libata переводится в ATA_CMD_FLUSH или ATA_CMD_FLUSH_EXT в зависимости от поддержки LBA48 диском) просто игнорировались. В коммите fa8e36c39b00a219d2c37250e493c3421e0e67e9 это было исправлено:

    [SCSI] fix barrier failure issue
    
    Currently, if the barrier command fails, the error return isn't seen
    by the block layer and it proceeds on regardless.  The problem is that
    SCSI always returns no error for REQ_TYPE_BLOCK_PC ... it expects the
    submitter to pick the errors out of req->errors, which the block
    barrier functions don't do.
    
    Since it appears that the way SG_IO and scsi_execute_request() work
    they discard the block error return and always use req->errors, the
    best fix for this is to have the SCSI layer return an error to block
    if one actually occurred (this also allows us to filter out spurious
    errors, like deferred sense).
    
    This patch is a bug fix that will need backporting to stable, but it's
    also quite a big change and in need of testing, so we'll incubate in
    the main kernel tree and backport at the -rc2 or so stage if no
    problems turn up.

Т.е., в новых ядрах существовавшая и ранее проблема (таймаут ATA_CMD_FLUSH_EXT) больше не игнорируется, а проявляется в явном виде, причём в случае md raid5 единственное место, где она может вылезти - запись суперблока RAID.

На машине с mcp67 по логам устойчиво отваливается hdc, а в SMART у него ненулевое значение Current_Pending_Sector - возможно, стоит запустить для него smartctl -t long.

Все прочие глючащие диски тоже SAMSUNG SP2504C, VT100-38? Или это вообще одни и те же диски на двух разных материнках?
Comment 9 Sergey Bolshakov 2009-01-10 18:16:10 MSK
диски, на которых происходили ошибки --  одни и те же, два SAMSUNG SP2504C. материнка менялась в попытках найти крайнего (при переезде с sb600 на mcp67
sdb/sdc поменялись местами друг с другом).
Возможно, в логах не видно, но: ошибки были на обоих дисках, с примерно
одинаковой частотой и суммарным количеством ~ 100-200 в неделю с момента
их приобретения; c переездом на .27 я отчётливо фиксировал случаи вываливания из рэйда каждого из них.

за рекомендации со smart спасибо, но тем не менее Current_Pending_Sector на одном из дисков равен трём уже с полгода, без видимых последствий.
Comment 10 Michail Yakushin 2009-01-11 21:01:13 MSK
И что с этим делать? Добовлять возможность игнорирования ошибок?
Comment 11 Michail Yakushin 2009-01-13 16:19:00 MSK
Видимо это бага в железе. Игнорировать подобные ошибки неправильно.
Comment 12 Mikhail Gusarov 2009-01-13 16:20:29 MSK
Как насчёт сообщить в LKML?

Это баг, не исправленный (и без workaround'а). Какой ещё NOTABUG?
Comment 13 Sergey Bolshakov 2009-03-22 14:08:08 MSK
после обновления фирмвари в дисках ошибки исчезли, так что видимо NOTABUG.
Comment 14 Sergey Bolshakov 2009-03-22 14:08:20 MSK
после обновления фирмвари в дисках ошибки исчезли, так что видимо NOTABUG.