Bug 82 - Seagate ST36422A does not work except with ide=nodma
Summary: Seagate ST36422A does not work except with ide=nodma
Status: CLOSED WONTFIX
Alias: None
Product: Sisyphus
Classification: Development
Component: kernel24-up (show other bugs)
Version: unstable
Hardware: all Linux
: P4 major
Assignee: Sergey Vlasov
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-10-17 20:56 MSD by Sergey Vlasov
Modified: 2006-12-23 22:42 MSK (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey Vlasov 2001-10-17 20:56:06 MSD
Возникла проблема при установке Junior 1.1 (ядро 2.4.9-alt4-up) на машину со следующей конфигурацией:

ABIT BX133-RAID (контроллер HPT не используется, занят только основной канал IDE, кабель 40-жильный)
Pentium III-533
/dev/hda - Seagate ST36422A (6400M)
/dev/hdb - ATAPI-CD ROM-DRIVE-50MAX (Acer)

Установка проходит нормально, при загрузке установленной системы с параметрами ядра по умолчанию (только root=/dev/hda3) происходит:

Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed ...
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hda:pio, hdb:pio
hda: ST36422A, ATA DISK drive
hdb: ATAPI-CD ROM-DRIVE-50MAX, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: 12500460 sectors (6400MB) w/256KiB Cache, CHS=778/255/63, UDMA(33)
Partition check:
 hda: hda1 hda2 hda3 hda4
......
reiserfs: checking transaction log (device 03:03)...
hda: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hda: drive not ready for command
hda: status error: status=0x50 { DriveReady SeekComplete }
hda: no DRQ after issuing WRITE
hda: status error: status=0x50 { DriveReady SeekComplete }
hda: no DRQ after issuing WRITE
hda: status error: status=0xd0 { Busy } 
ide0: reset: success

Дальше пытается идти нормальная загрузка, но на перемонтировании / в rw система зависает; после перезагрузки кнопкой RESET BIOS не обнаруживает ни диск, ни CD-ROM до выключения питания.

Отключение UDMA (и даже установка PIO0) в BIOS не помогает - все равно получается BIOS settings: hda:DMA, hdb:DMA.

Против этого безобразия помогла только опция ide=nodma, с которой удалось загрузиться, если указать ее сразу же после установки (после попытки загрузки без нее с вышеописанным зависанием были испорчены файлы, в частности, XF86Config - часть данных заменилась мусором).

Аналогичные проблемы с этим диском возникали при установке Mandrake 8.1 (ядро 2.4.8-??mdk), с той лишь разницей, что там они начались уже при установке (там установщик использует сразу ядро 2.4.8). Ядро 2.2.19, загружающееся с диска Junior, не пытается использовать DMA для этого диска, и установка проходит.

---

---

Comment 1 Bug Reporter 2001-10-31 13:00:41 MSK
Письмо с просьбой добавить указанный диск в \"черный список\" как неработающий в UDMA33 отправлен maintainer\'у подсистемы ide в ядрах 2.4.х
Comment 2 Bug Reporter 2001-10-31 13:00:41 MSK
Письмо с просьбой добавить указанный диск в \"черный список\" как неработающий в UDMA33 отправлен maintainer\'у подсистемы ide в ядрах 2.4.х
Comment 3 Bug Reporter 2001-10-31 13:04:18 MSK
Ждем исправлений в основном ядре. Пока рекомендую Вам пользоваться опцией nodma.
Comment 4 Bug Reporter 2001-10-31 13:04:18 MSK
Ждем исправлений в основном ядре. Пока рекомендую Вам пользоваться опцией nodma.
Comment 5 Michael Shigorin 2006-12-23 12:18:27 MSK
reopen...
Comment 6 Michael Shigorin 2006-12-23 12:20:56 MSK
1. Есть подозрение, что это бага диска (некоторые экземпляры очень криво
работают в DMA меньше максимального, например, UDMA33 вместо UDMA66/100 к такому
приводило -- тут и BX, и узкий шлейф это вынуждали).  Бишь WONTFIX.
2. Если вдруг получится проверить поведение с текущими ядрами на той комбинации
-- было бы интересно.
3. Вообще ты же сам теперь за ядро и отвечаешь :-)
Comment 7 Michael Shigorin 2006-12-23 12:21:37 MSK
см. п. 1
Comment 8 Sergey Vlasov 2006-12-23 16:30:51 MSK
Ну и зачем было открывать эту багу? :)

Тот хлам я теперь уже нигде не найду...
Comment 9 Michael Shigorin 2006-12-23 22:42:25 MSK
Так оно было псевдооткрытым -- CLOSED LATER. :)