Мой жесткий диск умирает?
Я получаю странные сообщения об ошибках в терминале.
Это вывод dmesg:
[3317.715990] ata4.00: исключение Emask 0x10 SAct 0x78 SErr 0x400000 действие 0x6 заморожено
[3317.716113] ata4.00: irq_stat 0x08000000, фатальная ошибка интерфейса
[3317.716199] ata4: SError: {Handshk}
[3317.716262] ata4.00: сбой команды: WRITE FPDMA QUEUED
[3317.716341] ata4.00: cmd 61/00: 18: 3f: 14: 13/04: 00: 00: 00: 00/40 tag 3 ncq 524288 out
[3317.716342] Рез. 40/00: 34: 17: 05: 13/00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[3317.716502] ata4.00: статус: {DRDY}
[3317.716563] ata4.00: сбой команды: WRITE FPDMA QUEUED
[3317.716634] ata4.00: cmd 61/00: 20: 3f: 18: 13/04: 00: 00: 00: 00/40 tag 4 ncq 524288 out
[3317.716635] Рез. 40/00: 34: 17: 05: 13/00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[3317.716795] ata4.00: статус: {DRDY}
[3317.716856] ata4.00: сбой команды: WRITE FPDMA QUEUED
[3317.716926] ata4.00: cmd 61/80: 28: 3f: 1c: 13/01: 00: 00: 00: 00/40 tag 5 ncq 196608 out
[3317.716927] Рез. 40/00: 34: 17: 05: 13/00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[3317.717087] ata4.00: статус: {DRDY}
[3317.717185] ata4.00: сбой команды: WRITE FPDMA QUEUED
[3317.717293] ata4.00: cmd 61/28: 30: 17: 05: 13/01: 00: 00: 00: 00/40 tag 6 ncq 151552 out
[3317.717293] Res 40/00: 34: 17: 05: 13/00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[3317.717606] ata4.00: статус: {DRDY}
[3317.717705] ata4: ссылка для жесткого сброса
[3318.208111] ata4: SATA-соединение со скоростью 6,0 Гбит / с (SStatus 133 SControl 300)
[3318.211624] ata4.00: настроено для UDMA / 133
[3318.211637] ata4: EH завершено
[4120.100879] ata4.00: исключение Emask 0x10 SAct 0x7fffff07 SErr 0x400000 действие 0x6 заморожено
[4120.101038] ata4.00: irq_stat 0x08000000, фатальная ошибка интерфейса
[4120.101147] ata4: SError: {Handshk}
[4120.101246] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.101353] ata4.00: cmd 61/00: 00: 3f: b0: 2d / 04: 00: 00: 00: 00/40 tag 0 ncq 524288 out
[4120.101354] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.101657] ata4.00: статус: {DRDY}
[4120.101755] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.101862] ata4.00: cmd 61/00: 08: 3f: b4: 2d / 04: 00: 00: 00: 00/40 tag 1 ncq 524288 out
[4120.101863] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.102169] ata4.00: статус: {DRDY}
[4120.102267] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.102373] ata4.00: cmd 61/00: 10: 3f: b8: 2d / 04: 00: 00: 00: 00/40 tag 2 ncq 524288 out
[4120.102374] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.102677] ata4.00: статус: {DRDY}
[4120.102775] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.102882] ata4.00: cmd 61/00: 40: 3f: a8: 2d / 04: 00: 00: 00: 00/40 tag 8 ncq 524288 out
[4120.102882] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.103186] ata4.00: статус: {DRDY}
[4120.103284] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.103390] ata4.00: cmd 61/00: 48: 3f: ac: 2d / 04: 00: 00: 00: 00/40 tag 9 ncq 524288 out
[4120.103391] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.103695] ata4.00: статус: {DRDY}
[4120.103792] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.103899] ata4.00: cmd 61/00: 50: 3f: bc: 2d / 04: 00: 00: 00: 00/40 tag 10 ncq 524288 out
[4120.103900] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.104216] ata4.00: статус: {DRDY}
[4120.104315] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.104424] ata4.00: cmd 61/00: 58: 3f: c0: 2d / 04: 00: 00: 00: 00/40 tag 11 ncq 524288 out
[4120.104425] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.104730] ata4.00: статус: {DRDY}
[4120.104829] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.104937] ata4.00: cmd 61/00: 60: 3f: c4: 2d / 04: 00: 00: 00: 00/40 tag 12 ncq 524288 out
[4120.104938] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.105243] ata4.00: статус: {DRDY}
[4120.105342] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.105450] ata4.00: cmd 61/00: 68: 3f: c8: 2d / 04: 00: 00: 00: 00/40 tag 13 ncq 524288 out
[4120.105451] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.105756] ata4.00: статус: {DRDY}
[4120.105855] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.105963] ata4.00: cmd 61/00: 70: 3f: cc: 2d / 04: 00: 00: 00: 00/40 tag 14 ncq 524288 out
[4120.105964] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.106269] ata4.00: статус: {DRDY}
[4120.106368] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.106476] ata4.00: cmd 61/00: 78: 3f: d0: 2d / 04: 00: 00: 00: 00/40 tag 15 ncq 524288 out
[4120.106477] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.106782] ata4.00: статус: {DRDY}
[4120.106881] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.106990] ata4.00: cmd 61/00: 80: 3f: d4: 2d / 04: 00: 00: 00: 00/40 tag 16 ncq 524288 out
[4120.106990] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.107295] ata4.00: статус: {DRDY}
[4120.107394] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.107502] ata4.00: cmd 61/00: 88: 3f: d8: 2d / 04: 00: 00: 00: 00/40 tag 17 ncq 524288 out
[4120.107503] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.107808] ata4.00: статус: {DRDY}
[4120.107907] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.108024] ata4.00: cmd 61/00: 90: 3f: dc: 2d / 04: 00: 00: 00: 00/40 tag 18 ncq 524288 out
[4120.108025] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.108332] ata4.00: статус: {DRDY}
[4120.108433] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.108542] ata4.00: cmd 61/00: 98: 3f: e0: 2d / 04: 00: 00: 00: 00/40 tag 19 ncq 524288 out
[4120.108543] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.108848] ata4.00: статус: {DRDY}
[4120.108949] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.109058] ata4.00: cmd 61/00: a0: 3f: e4: 2d / 04: 00: 00: 00: 00/40 tag 20 ncq 524288 out
[4120.109059] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.109365] ata4.00: статус: {DRDY}
[4120.109463] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.109573] ata4.00: cmd 61/00: a8: 3f: e8: 2d / 04: 00: 00: 00: 00/40 tag 21 ncq 524288 out
[4120.109574] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.109881] ata4.00: статус: {DRDY}
[4120.109981] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.110090] ata4.00: cmd 61/00: b0: 3f: ec: 2d / 04: 00: 00: 00: 00/40 tag 22 ncq 524288 out
[4120.110091] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.110396] ata4.00: статус: {DRDY}
[4120.110496] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.110604] ata4.00: cmd 61/00: b8: 3f: f0: 2d / 04: 00: 00: 00: 00/40 tag 23 ncq 524288 out
[4120.110606] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.110911] ata4.00: статус: {DRDY}
[4120.111010] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.111118] ata4.00: cmd 61/00: c0: 3f: f4: 2d / 04: 00: 00: 00: 00/40 tag 24 ncq 524288 out
[4120.111119] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.111425] ata4.00: статус: {DRDY}
[4120.111523] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.111632] ata4.00: cmd 61/00: c8: 3f: f8: 2d / 04: 00: 00: 00: 00/40 tag 25 ncq 524288 out
[4120.111633] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.111938] ata4.00: статус: {DRDY}
[4120.112052] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.112162] ata4.00: cmd 61/00: d0: 3f: fc: 2d / 04: 00: 00: 00: 00/40 tag 26 ncq 524288 out
[4120.112163] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.112468] ata4.00: статус: {DRDY}
[4120.112566] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.112675] ata4.00: cmd 61/00: d8: 3f: 00: 2e / 04: 00: 00: 00: 00/40 tag 27 ncq 524288 out
[4120.112676] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.112981] ata4.00: статус: {DRDY}
[4120.113079] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.113188] ata4.00: cmd 61/00: e0: 3f: 04: 2e / 04: 00: 00: 00: 00/40 tag 28 ncq 524288 out
[4120.113189] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.113493] ata4.00: статус: {DRDY}
[4120.113596] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.113705] ata4.00: cmd 61/00: e8: 3f: 08: 2e / 04: 00: 00: 00: 00/40 tag 29 ncq 524288 out
[4120.113706] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.114012] ata4.00: статус: {DRDY}
[4120.114112] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.114220] ata4.00: cmd 61/80: f0: 3f: 0c: 2e / 02: 00: 00: 00: 00/40 tag 30 ncq 327680 out
[4120.114221] res 40/00: f4: 3f: 0c: 2e / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.114527] ata4.00: статус: {DRDY}
[4120.114628] ata4: ссылка для жесткого сброса
[4120.604112] ata4: SATA-соединение со скоростью 6,0 Гбит / с (SStatus 133 SControl 300)
[4120.607305] ata4.00: настроено для UDMA / 133
[4120.607328] ata4: EH завершено
[4120.625081] ata4.00: исключение Emask 0x10 SAct 0x3ff0000 SErr 0x400000 действие 0x6 заморожено
[4120.625238] ata4.00: irq_stat 0x08000000, фатальная ошибка интерфейса
[4120.625347] ata4: SError: {Handshk}
[4120.625446] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.625553] ata4.00: cmd 61/00: 80: 3f: cc: 2d / 04: 00: 00: 00: 00/40 tag 16 ncq 524288 out
[4120.625554] Рез. 40/00: Копия: 3f: b0: 2d / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.625858] ata4.00: статус: {DRDY}
[4120.625956] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.626063] ata4.00: cmd 61/00: 88: 3f: c8: 2d / 04: 00: 00: 00: 00/40 tag 17 ncq 524288 out
[4120.626064] Рез. 40/00: Копия: 3f: b0: 2d / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.635853] ata4.00: статус: {DRDY}
[4120.635952] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.636072] ata4.00: cmd 61/00: 90: 3f: c4: 2d / 04: 00: 00: 00: 00/40 tag 18 ncq 524288 out
[4120.636073] Рез. 40/00: Копия: 3f: b0: 2d / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.636377] ata4.00: статус: {DRDY}
[4120.636474] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.636580] ata4.00: cmd 61/00: 98: 3f: c0: 2d / 04: 00: 00: 00: 00/40 tag 19 ncq 524288 out
[4120.636581] Рез 40/00: Копия: 3f: b0: 2d / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.636883] ata4.00: статус: {DRDY}
[4120.636981] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.637087] ata4.00: cmd 61/00: a0: 3f: bc: 2d / 04: 00: 00: 00: 00/40 tag 20 ncq 524288 out
[4120.637088] Рез. 40/00: Копия: 3f: b0: 2d / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.637397] ata4.00: статус: {DRDY}
[4120.637495] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.637601] ata4.00: cmd 61/00: a8: 3f: ac: 2d / 04: 00: 00: 00: 00/40 tag 21 ncq 524288 out
[4120.637601] Рез. 40/00: Копия: 3f: b0: 2d / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.637902] ata4.00: статус: {DRDY}
[4120.638000] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.638105] ata4.00: cmd 61/00: b0: 3f: a8: 2d / 04: 00: 00: 00: 00/40 tag 22 ncq 524288 out
[4120.638106] Рез 40/00: Копия: 3f: b0: 2d / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.638407] ata4.00: статус: {DRDY}
[4120.638504] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.638610] ata4.00: cmd 61/00: b8: 3f: b8: 2d / 04: 00: 00: 00: 00/40 tag 23 ncq 524288 out
[4120.638610] Рез 40/00: Копия: 3f: b0: 2d / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.638911] ata4.00: статус: {DRDY}
[4120.639009] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.639114] ata4.00: cmd 61/00: c0: 3f: b4: 2d / 04: 00: 00: 00: 00/40 tag 24 ncq 524288 out
[4120.639115] Рез. 40/00: Копия: 3f: b0: 2d / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.639416] ata4.00: статус: {DRDY}
[4120.639513] ata4.00: сбой команды: WRITE FPDMA QUEUED
[4120.639618] ata4.00: cmd 61/00: c8: 3f: b0: 2d / 04: 00: 00: 00: 00/40 tag 25 ncq 524288 out
[4120.639619] Рез. 40/00: Копия: 3f: b0: 2d / 00: 00: 00: 00: 00/40 Emask 0x10 (ошибка шины ATA)
[4120.639920] ata4.00: статус: {DRDY}
[4120.640035] ata4: ссылка для жесткого сброса
[4121.132104] ata4: SATA-соединение со скоростью 6,0 Гбит / с (SStatus 133 SControl 300)
[4121.134760] ata4.00: настроено для UDMA / 133
[4121.134773] ata4: EH завершено
Значит ли это, что мой жесткий диск умирает?
Ответы:
Источник питания! Эти ошибки обычно связаны с неисправным кабелем или кабельным разъемом или, возможно, с плохим питанием. Наличие BadCRC или ICRC — довольно хороший показатель низкого качества кабеля SATA. Однако, если более качественный кабель не решает проблему, то это, вероятно, проблема с питанием (слабый кабель питания или соединение задней панели, плохие разъемы, плохой разветвитель питания, перегруженный источник питания, слишком много дисков на шине питания, плохой источник питания и т. Д. ).
Скорее всего, это не ваш жесткий диск, скорее всего, это кабель ATA или шина ATA. попробуйте проверить кабель ATA и / или заменить его на другой кабель. также попробуйте подключить жесткий диск к другой шине ATA на материнской плате.
Проверьте эту ссылку для получения дополнительной информации: https://ata.wiki.kernel.org/index.php/Libata_error_messages
У меня есть пара серверов, по 2 жестких диска в RAID1 в каждом.
с кабелями SATA, встроенными производителем, и с ~50% кабелей, которые я покупаю, я получаю следующие сообщения:
failed command: WRITE FPDMA QUEUED [ 4.437904] ata1.00: cmd 61/08:d0:a0:41:21/00:00:02:00:00/40 tag 26 ncq 4096 out
res 40/00:b8:20:28:60/00:00:02:00:00/40 Emask 0x10 (ATA bus error)
я пытался вставить эти (от производителя) кабели в свой компьютер, и они работали нормально, я также не верю, что половина различных кабелей, которые я купил (я купил 14 разных кабелей, 6 из них выдали мне эту ошибку), сломаны с завода .
В чем могут быть причины этой ошибки (имея в виду, что замена кабелей на правильные решает проблему, а с самими дисками по SMART статусу вообще проблем нет и с соответствующим кабелем ошибок не выдает) , и какие могут быть отличия кабелей sata, которые могут привести к такому различному поведению?
Спасибо за Ваш ответ заранее!
В моем ноутбуке Lenovo IdeaPad Z500-Touch есть внутренний разъем SATA и жесткий диск. Независимо от того, какой жесткий диск (пробовал жесткий диск объемом 1 ТБ и жесткий диск объемом 2 ТБ) или твердотельный накопитель (Samsung Extreme 256 ГБ) я вставил в caddy (пробовал два разных, один из hddcaddy.com, другой неизвестный), через несколько недель я испытываю первый ATA bus error записываются в kern.log которые, по-видимому, исправимы . В течение одной недели число случаев возрастает, так что загрузка задерживается (до 1 минуты) из-за сотен ошибок шины ATA. В какой-то момент ошибки записи разрушают файловую систему btrfs я должен восстановить из резервной копии.
Как только я отключил и снова подключил жесткий диск, в течение нескольких недель не было ошибок шины ATA, и сценарий начинался так же. Я испытал это> 3 раза сейчас. Я не вижу коррозии на разъеме SATA и винты надежно закреплены.
Я испытал это на Linux 4.3.0 и 4.3.3, но то, как эта проблема решается, заставляет меня сомневаться, что это проблема программного обеспечения.
I have an SSD in my system and an external hard drive (attached via eSATA) as a backup medium. I use «rsync» to synchronize the internal drive to the external drive. My backup drive was once a Seagate ST1000LM024. The problem is, I always got file system corruption on the drive, either the file-system became read-only or was full of empty directories or even the superblock was damaged. When I formatted the drive, I could sometimes use it again, though it would fail again soon. In the end, I couldn’t even format the drive anymore.
I thought that the drive was bad (even though it didn’t show any SMART errors) and replaced it with a more pricy Western Digital WD10JPVX.
After I replaced the drive, I could use the new one for several months, then corruption started to appear on the new drive as well. I formatted it again and got it back to a working state. Today it failed again. I formatted it, but it failed on the first pass of new data written to it. So I thought it might be a problem related to «rsync», perhaps it’s writing lots of data in parallel and the drive «hiccups» on that. So I went with ordinary «cp» for copying the data to it. It went well for quite some time, then it failed again.
In my opinion, the SMART data doesn’t look too suspicious.
# smartctl -a /dev/sdc
smartctl 6.4 2015-06-04 r4109 [x86_64-linux-4.4.6-300.fc23.x86_64] (local build)
Copyright (C) 2002-15, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Blue Mobile
Device Model: WDC WD10JPVX-22JC3T0
Serial Number: [removed]
LU WWN Device Id: [removed]
Firmware Version: 01.01A01
User Capacity: 1.000.204.886.016 bytes [1,00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 5400 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2 (minor revision not indicated)
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 1.5 Gb/s)
Local Time is: Tue Apr 12 18:42:47 2016 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: (17640) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 198) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x7035) SCT Status supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 180 174 021 Pre-fail Always - 1991
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 57
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 14
10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 33
191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 30
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 44
194 Temperature_Celsius 0x0022 109 094 000 Old_age Always - 38
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 1
200 Multi_Zone_Error_Rate 0x0008 100 253 000 Old_age Offline - 0
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
#
However, dmesg shows lots of these …
[12609.913805] ata4.00: exception Emask 0x10 SAct 0x700000 SErr 0x400100 action 0x6 frozen
[12609.913817] ata4.00: irq_stat 0x08000000, interface fatal error
[12609.913824] ata4: SError: { UnrecovData Handshk }
[12609.913832] ata4.00: failed command: WRITE FPDMA QUEUED
[12609.913843] ata4.00: cmd 61/00:a0:00:29:ad/08:00:09:00:00/40 tag 20 ncq 1048576 out
res 40/00:b4:00:60:ad/00:00:09:00:00/40 Emask 0x10 (ATA bus error)
[12609.913849] ata4.00: status: { DRDY }
[12609.913853] ata4.00: failed command: WRITE FPDMA QUEUED
[12609.913863] ata4.00: cmd 61/00:a8:00:20:ad/09:00:09:00:00/40 tag 21 ncq 1179648 out
res 40/00:b4:00:60:ad/00:00:09:00:00/40 Emask 0x10 (ATA bus error)
[12609.913867] ata4.00: status: { DRDY }
[12609.913871] ata4.00: failed command: WRITE FPDMA QUEUED
[12609.913880] ata4.00: cmd 61/00:b0:00:60:ad/09:00:09:00:00/40 tag 22 ncq 1179648 out
res 40/00:b4:00:60:ad/00:00:09:00:00/40 Emask 0x10 (ATA bus error)
[12609.913885] ata4.00: status: { DRDY }
Anyone knows what’s the problem here and what I should do? I don’t feel safe without a working backup drive.
This is on a Fedora 23 system with Kernel 4.4.6-300. There might be some more recent version, however, I actually wanted to back that thing up before applying the latest updates, which is why I ran into these problems in the first place.
- Печать
Страницы: [1] 2 Все Вниз
Тема: Ошибка шины (Прочитано 7799 раз)
0 Пользователей и 1 Гость просматривают эту тему.
Tupas
Значит, ввожу в консоли sudo apt-get install любое_имя_пакета, а в ответ получаю кучу текста такого вида:
[ 2927.929002] ata1.00: status: { DRDY ERR }Что делать?
[ 2927.942856] ata1.00: error: { UNC }
[ 2931.680190] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 2931.694304] ata1.00: BDMA stat 0x25
[ 2931.708326] ata1.00: failed command: READ DMA
[ 2931.722101] ata1.00: cmd c8/00:08:08:a5:0c/00:00:00:00:00/e0 tag 0 dma 4096 in
[ 2931.722107] ata1.00: res 51/40:03:0c:a5:0c/00:00:00:00:00/e0 Emask 0x9 (media error)
[ 2931.777373] ata1.00: status: { DRDY ERR }
[ 2931.791188] ata1.00: error: { UNC }
[ 2931.828780] end_request: I/O error, dev sda, sector 828684
Ошибка шины
Deathrose
Что делать?
Проверьте кабели)) Проверьте жесткий диск)))
sht0rm
Заменить кабель, заменить жесткий диск.
Tupas
Ну, кабель заменить попробую. А чем можно жёсткий диск проверить?
sht0rm
666joy666
Было у меня точно так же…end-to-end error, если точней, можно посмотреть в SMART…
Решается заменой шлейфа, воткнуть шлейф в иной порт, взять иной кабель, и как апофез — сменить винт.
Pace!
Если это проблема с жёстким диском, то ведь она должна распространятся на всё, а не только на установку, так ведь?
666joy666
Если это проблема с жёстким диском, то ведь она должна распространятся на всё, а не только на установку, так ведь?
Эта ошибка не столь критична…у меня она вылазила только если я один файл пытался скопировать с одного раздела на иной, больше её не видел…
nd3
mhdd, victoria
Вы же в UBUNTU!!!
Проверить диск на битые сектора:
badblocks -v /dev/sda
MA3X
2931.791188] ata1.00: error: { UNC } — это открытым текстом сбойный сектор на харде.
невосстановимая ошибка чтения.
Винт или мучить mhdd, или менять. второе — предпочтительнее
Microsoft isn’t the answer.
Microsoft is the question, and the answer is NO.
Tupas
Нашлось 120 плохих блоков, и как их чинить?
nd3
Как чинить? badblocks -vw /dev/sda(1) это с проверкой на запись.
Внимание!!!! Вся информация будет уничтожена!
Сектора которые не пройдут тест запись-чтение, будут перенесены SMARTом в дефект лист. А по большому счету выход один — замена винчестера.
Tupas
Как чинить? badblocks -vw /dev/sda(1) это с проверкой на запись.
Внимание!!!! Вся информация будет уничтожена!
А без уничтожения никак что ли?
И это же наверное с другого диска делать надо?
nd3
Как чинить? badblocks -vw /dev/sda(1) это с проверкой на запись.
Внимание!!!! Вся информация будет уничтожена!А без уничтожения никак что ли?
И это же наверное с другого диска делать надо?
Никак, совсем. Это очевидно. 
MA3X
Я допускаю для винта не более 5-7 бб на всей поверхности, чтобы считать его еще нормальным.
Если больше — то как минимум не в рабочие машины. Временное хранение некритичных данных.
А 120 — однозначно втопка_гореть.
Microsoft isn’t the answer.
Microsoft is the question, and the answer is NO.
- Печать
Страницы: [1] 2 Все Вверх
В конце концов, кажется, это были кабели.
Следуя предложению в отчете об ошибке, я заменил кабель SATA, использовал другой разъем питания SATA от моего источника питания (возможный виновник недостаточное питание) и убедился, что кабель SATA не был рядом другие силовые кабели (возможны электрические помехи от других, особенно силовых, кабелей).
Теперь он отлично работает.
С тех пор я вставил оригинальный кабель SATA, и он все еще работает. Я скоро переключу кабели питания и попробую повесить кабель SATA рядом с другими кабелями питания … Вероятно, кабель SATA был либо смещен, либо возникло плохое соединение из-за влажности или чего-то подобного.
ответ дан drevicko
30 May 2012 в 08:37
поделиться
|
# (отредактировано 6 лет, 3 месяца назад) |
|
|
Темы: 1 Сообщения: 20 Участник с: 30 октября 2014 |
Всем доброе время суток! Проблема такого плана. В частном доме часто плохое напряжение, и поэтому ПК работает через стабилизатор. (УПС нет) и комп часто вырубался жестко из-за этого полетело, что то в системе !!! Некоторый софт не запускается …. Вот ошибка firefox
[Child 9482] WARNING: pipe error (3): Соединение разорвано другой стороной: file /build/firefox/src/firefox-49.0.1/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 316 |
|
vasek |
# (отредактировано 6 лет, 3 месяца назад) |
|
Темы: 47 Сообщения: 11417 Участник с: 17 февраля 2013 |
Информации практически нет, гадать нет смысла… Ошибка шины (core dumped) — лучше погуглить по Bus error (core dumped), но вряд ли без уточнения проблемы что то можно толковое нагуглить …. а для сбора информации 1. Лучше сначала просмотреть внимательно логи — возможно есть какие то настораживающие записи перед падением … 2. Посмотри наличие коры…. $ coredumpctl list … (или в ручную — /var/lib/systemd/coredump/) — если есть в наличии, попробуй запустить в gdb …. хотя бы посмотреть, где падают …. 3. Можно попробовать потрейсить (strace) по системным вызовам … 4. Если это выскакивает у многих приложений, то это может быть связано и с аппаратными проблемами — неплохо проверить HDD и память Ошибки не исчезают с опытом — они просто умнеют |
|
vadik |
# (отредактировано 6 лет, 3 месяца назад) |
|
Темы: 55 Сообщения: 5410 Участник с: 17 августа 2009 |
vasek, есть еще нулевой вариант — просто переустановить проблемные приложения. Только это все до лампочки. Следующий скачек напряжения может отправить в небытие и материнку, и ЖД и пр. пр. пр. Бороться в первую очередь нужно с причиной, а не с последствиями. |
|
Aivar |
# |
|
Темы: 4 Сообщения: 6897 Участник с: 17 февраля 2011 |
Жестко полетело в файловой системе. vadik, прав. |
|
ErV |
# |
|
Темы: 18 Сообщения: 121 Участник с: 03 июня 2015 |
У меня была такая ерунда когда сбоила ОЗУ, причем это проявлялось редко и по разному, но подобные ошибки были как в firefox так и в chromium. Gold Memory Test в режиме Thorough на ночь помогут вам подтвердить или исключить этот пункт. |
|
lampslave |
# |
|
Темы: 32 Сообщения: 4800 Участник с: 05 июля 2011 |
Точняк. Привезли мужика с топором в спине — а давайте ему температуру померим, может грипп у него? Купите уже УПС, не гробьте технику. |
|
vasek |
# |
|
Темы: 47 Сообщения: 11417 Участник с: 17 февраля 2013 |
lampslave, ты прав — топор нужно извлекать в первую очередь и, при необходимости, переводить в реанимцию, чтобы привести в чувство…… но рана то сама по себе никуда не исчезнет, все равно нужно лечить (после того как переведут в обычную палату) ……… если не лечить может образоваться и сепсис или что другое …….
Ошибки не исчезают с опытом — они просто умнеют |
mmap минимальный пример POSIX 7
«Ошибка шины» происходит, когда ядро отправляет SIGBUS в процесс.
Минимальный пример, который создает его, потому что ftruncate был забыт:
#include <fcntl.h> /* O_ constants */
#include <unistd.h> /* ftruncate */
#include <sys/mman.h> /* mmap */
int main() {
int fd;
int *map;
int size = sizeof(int);
char *name = "/a";
shm_unlink(name);
fd = shm_open(name, O_RDWR | O_CREAT, (mode_t)0600);
/* THIS is the cause of the problem. */
/*ftruncate(fd, size);*/
map = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
/* This is what generates the SIGBUS. */
*map = 0;
}
Запустить с помощью:
gcc -std=c99 main.c -lrt
./a.out
Протестировано в Ubuntu 14.04.
POSIX описывает SIGBUS как:
Доступ к части undefined объекта памяти.
спецификация mmap говорит, что:
Ссылки в диапазоне адресов, начинающиеся с pa и продолжающиеся для len-байтов на целые страницы, следующие за концом объекта, должны привести к передаче сигнала SIGBUS.
И shm_open говорит, что он генерирует объекты размером 0:
Объект общей памяти имеет нулевой размер.
Итак, при *map = 0 мы касаемся конца выделенного объекта.
Спокойно работал, вдруг, всё стало доступно только для чтения, браузер не смог открывать страницы, ничего не компилируется, не запускается, терминал тоже глючит. Потом мне во включенном терминале написало:
Код
KeyboardInterrupt
Traceback (most recent call last):
File "/usr/lib/command-not-found", line 1, in <module>
KeyboardInterrupt
KeyboardInterrupt
^C
На любые существующие команды — «Ошибка шины», на несуществующие вообще ничего не пишет (даже то, что команда отсутствует)
Сейчас всё нормально загружается, но, по-моему, только в оперативку. Диск стал доступен только для чтения. В чём дело?
Ещё несколько команд проделал:
Код
root@vladiator:~# cd gaming #нормально root@vladiator:~/gaming# ls #нормально vlacer root@vladiator:~/gaming# cd vlacer #нормально root@vladiator:~/gaming/vlacer# ./jojee #ненормально bash: ./jojee: Нет такого файла или каталога root@vladiator:~/gaming/vlacer# ls #Ненормально Ошибка шины
В общем, я не знаю, какая информация нужна, спрашивайте её, если надо. Могу сказать лишь то, что у меня огромные проблемы.
Недавно открывал системник и закрыл его. Возможно, что-то там слетело (тем более, у меня в последнее время часто кабель для соединения диска с материнкой отваливается), но проверил соединение — вроде норм.
Добавлено через 1 минуту
Код
root@vladiator:~/gaming/vlacer# badblocks -v /dev/sda bash: /sbin/badblocks: Ошибка ввода/вывода
Добавлено через 3 минуты
Если бы диск полностью отрубился, то gnome-panel бы вылетел и появилось сообщение с кучей квадратов (как при отключении диска и rm -rf)
Добавлено через 5 минут
Сделал перезапуск, всё нормально, но хотелось бы узнать, из-за чего это было. Возможно, соединение действительно ненадолго пропало, но могло ли это привести к таким последствиям?
- Печать
Страницы: [1] 2 Все Вниз
Тема: Ошибка шины (Прочитано 7629 раз)
0 Пользователей и 1 Гость просматривают эту тему.
Tupas
Значит, ввожу в консоли sudo apt-get install любое_имя_пакета, а в ответ получаю кучу текста такого вида:
[ 2927.929002] ata1.00: status: { DRDY ERR }Что делать?
[ 2927.942856] ata1.00: error: { UNC }
[ 2931.680190] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 2931.694304] ata1.00: BDMA stat 0x25
[ 2931.708326] ata1.00: failed command: READ DMA
[ 2931.722101] ata1.00: cmd c8/00:08:08:a5:0c/00:00:00:00:00/e0 tag 0 dma 4096 in
[ 2931.722107] ata1.00: res 51/40:03:0c:a5:0c/00:00:00:00:00/e0 Emask 0x9 (media error)
[ 2931.777373] ata1.00: status: { DRDY ERR }
[ 2931.791188] ata1.00: error: { UNC }
[ 2931.828780] end_request: I/O error, dev sda, sector 828684
Ошибка шины
Deathrose
Что делать?
Проверьте кабели)) Проверьте жесткий диск)))
sht0rm
Заменить кабель, заменить жесткий диск.
Tupas
Ну, кабель заменить попробую. А чем можно жёсткий диск проверить?
sht0rm
666joy666
Было у меня точно так же…end-to-end error, если точней, можно посмотреть в SMART…
Решается заменой шлейфа, воткнуть шлейф в иной порт, взять иной кабель, и как апофез — сменить винт.
Pace!
Если это проблема с жёстким диском, то ведь она должна распространятся на всё, а не только на установку, так ведь?
666joy666
Если это проблема с жёстким диском, то ведь она должна распространятся на всё, а не только на установку, так ведь?
Эта ошибка не столь критична…у меня она вылазила только если я один файл пытался скопировать с одного раздела на иной, больше её не видел…
nd3
mhdd, victoria
Вы же в UBUNTU!!!
Проверить диск на битые сектора:
badblocks -v /dev/sda
MA3X
2931.791188] ata1.00: error: { UNC } — это открытым текстом сбойный сектор на харде.
невосстановимая ошибка чтения.
Винт или мучить mhdd, или менять. второе — предпочтительнее
Microsoft isn’t the answer.
Microsoft is the question, and the answer is NO.
Tupas
Нашлось 120 плохих блоков, и как их чинить?
nd3
Как чинить? badblocks -vw /dev/sda(1) это с проверкой на запись.
Внимание!!!! Вся информация будет уничтожена!
Сектора которые не пройдут тест запись-чтение, будут перенесены SMARTом в дефект лист. А по большому счету выход один — замена винчестера.
Tupas
Как чинить? badblocks -vw /dev/sda(1) это с проверкой на запись.
Внимание!!!! Вся информация будет уничтожена!
А без уничтожения никак что ли?
И это же наверное с другого диска делать надо?
nd3
Как чинить? badblocks -vw /dev/sda(1) это с проверкой на запись.
Внимание!!!! Вся информация будет уничтожена!А без уничтожения никак что ли?
И это же наверное с другого диска делать надо?
Никак, совсем. Это очевидно.
MA3X
Я допускаю для винта не более 5-7 бб на всей поверхности, чтобы считать его еще нормальным.
Если больше — то как минимум не в рабочие машины. Временное хранение некритичных данных.
А 120 — однозначно втопка_гореть.
Microsoft isn’t the answer.
Microsoft is the question, and the answer is NO.
- Печать
Страницы: [1] 2 Все Вверх
Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 17:22, 21 мая 2019.
Ошибка на шине (bus error)- это ошибка, которая была вызвана аппаратным обеспечением, уведомляющим операционную систему о том , что процесс пытается получить доступ к памяти, которую процессор не может физически адресовать из-за того, что у адресной шины недопустимый адрес, а следовательно, и имя. В современном использовании на большинстве архитектур они встречаются гораздо реже , чем ошибки сегментации, которые возникают в основном из-за нарушений доступа к памяти: проблем с логическим адресом или разрешениями.
На платформах, совместимых с портативным интерфейсом операционной системы( POSIX), ошибки шины обычно приводят к тому, что сигнал SIGBUS, который сигнализирует об ошибке шины, при обращении к физической памяти, передается процессу, который вызвал ошибку. SIGBUS также может быть вызван любой общей неисправностью устройства, которую обнаруживает компьютер, хотя ошибка шины редко означает, что компьютерное оборудование физически сломано, в основном это вызвано ошибкой в программном обеспечении.
Содержание
- 1 Причины возникновения
- 1.1 Недействующий адрес
- 1.2 Несогласованный доступ
- 1.3 Ошибка страницы
- 1.4 Несуществующий сегмент(x86)
- 2 Источники
Причины возникновения
Существует 4 основных причины возникновения данной ошибки.
Рассмотрим каждую из них.
Недействующий адрес
Программное обеспечение указывает процессору на чтение или запись определенного адреса физической памяти . Соответственно, центральный процессор устанавливает этот физический адрес на своей адресной шине и запрашивает все другое оборудование, подключенное к нему, чтобы ответить с результатами, если они отвечают за этот конкретный адрес. Если никакое другое оборудование не отвечает, центральный процессор вызывает исключение, указывающее, что запрошенный физический адрес не распознан всей компьютерной системой. Состоит отметить, что это касается только физических адресов памяти. Попытка доступа к неопределенному адресу виртуальной памяти обычно считается ошибкой сегментации, а не ошибкой шины, хотя если блок управления памятью (MMU) является отдельным, процессор не может определить разницу.
Несогласованный доступ
В основном центральные процессоры (CPU) являются байт-адресуемыми, где каждый уникальный адрес памяти ссылается на 8-битный байт . Большинство из них могут получить доступ к отдельным байтам из каждого адреса памяти, но они, как правило, не могут получить доступ к более крупным блокам (16 бит, 32 бит, 64 бит и т. д.) без «выравнивания» структуры данных этих блоков к определенной границе.
К примеру, если многобайтовый доступ должен быть 16-битным, адреса (заданные в байтах) в 0, 2, 4, 6 и так далее будут считаться выровненными и, следовательно, доступными, в то время как адреса 1, 3, 5 и так далее будут считаться не выровненными. Аналогично, если многобайтовый доступ должен быть 32-разрядным, адреса 0, 4, 8, 12 и так далее будут считаться выровненными и, следовательно, доступными, а все промежуточные адреса будут считаться не выровненными. Попытка получить доступ к блоку размером больше байта по не выровненному адресу может привести к ошибке шины.
Некоторые системы могут быть смешанные в зависимости от используемой архитектуры. Например, для аппаратного обеспечения, основанного на мэйнфрейме IBM System/360 , включая IBM System z, Fujitsu B8000, RCA Spectra и UNIVAC Series 90 , инструкции должны находиться на 16-разрядной границе, то есть адреса выполнения должны начинаться с четного байта. Попытка ветвления на нечетный адрес приводит к исключению спецификации. Данные, однако, могут быть извлечены из любого адреса в памяти, и могут быть размером от одного байта или больше, в зависимости от инструкции.
Процессоры, как правило, получают доступ к данным на всей ширине своей шины данных в любое время.
Система связи , которая передает данные между компонентами внутри компьютера или между компьютерами.Шина это система связи , которая передает данные между компонентами внутри компьютера или между компьютерами. Чтобы обратиться к байтам, они обращаются к памяти на всей ширине своей шины данных, затем маскируют и сдвигают для обращения к отдельному байту. Системы терпят этот неэффективный алгоритм, так как он является неотъемлемой особенностью большинства программ, особенно обработки строк. В отличие от байтов, большие блоки могут охватывать два выровненных адреса и, таким образом, требуют более одной выборки на шине данных. Процессоры могут поддерживать эту функцию, но эта функциональность редко требуется непосредственно в машинном коде уровень, таким образом, проектировщики центрального процессора обычно избегают его реализации и вместо этого выдают ошибки шины для не выровненного доступа к памяти.
Ошибка страницы
Такие ОС как,FreeBSD, Linux и Solaris могут сигнализировать об ошибке шины, когда страницы виртуальной памяти не могут быть выгружены, например, потому, что она исчезла (например, доступ к файлу с отображением памяти или выполнение двоичного образа, который был усечен во время работы программы), или потому, что только что созданный файл с отображением памяти не может быть физически выделен, потому что диск заполнен.
Несуществующий сегмент(x86)
На x86(емейство архитектур наборов команд,основанных на микропроцессоре Intel 8086 ) существует старый механизм управления памятью, известный как сегментация. Если приложение загружает регистр сегмента с селектором несуществующего сегмента , генерируется исключение. Некоторые ОС использовали это для подкачки, но под Linux это генерирует SIGBUS.
Источники
- https://stackoverflow.com/questions/212466/what-is-a-bus-error
- https://www.geeksforgeeks.org/segmentation-fault-sigsegv-vs-bus-error-sigbus/
- https://studfiles.net/preview/307512/page:15/
Что такое ошибка шины?
Что означает сообщение об ошибке шины и чем оно отличается от сегфоута?
Ответы:
В настоящее время ошибки шины встречаются редко на x86 и возникают, когда ваш процессор не может даже попытаться получить доступ к памяти, как правило:
- использование инструкции процессора с адресом, который не удовлетворяет его требованиям выравнивания.
Ошибки сегментации возникают при доступе к памяти, которая не принадлежит вашему процессу, они очень распространены и обычно являются результатом:
- используя указатель на то, что было освобождено.
- используя неинициализированный, следовательно, фиктивный указатель.
- используя нулевой указатель.
- переполнение буфера.
PS: если быть более точным, это не манипулирование самим указателем, который вызовет проблемы, это доступ к памяти, на которую он указывает (разыменование).
Segfault обращается к памяти, к которой у вас нет доступа. Это только для чтения, у вас нет разрешения и т.д …
Ошибка шины пытается получить доступ к памяти, которая не может быть там. Вы использовали адрес, который не имеет смысла для системы, или неправильный адрес для этой операции.
mmap минимальный пример POSIX 7
«Ошибка шины» возникает, когда ядро отправляет SIGBUSпроцесс.
Минимальный пример, который производит это, потому что ftruncateбыл забыт:
#include <fcntl.h> /* O_ constants */
#include <unistd.h> /* ftruncate */
#include <sys/mman.h> /* mmap */
int main() {
int fd;
int *map;
int size = sizeof(int);
char *name = "/a";
shm_unlink(name);
fd = shm_open(name, O_RDWR | O_CREAT, (mode_t)0600);
/* THIS is the cause of the problem. */
/*ftruncate(fd, size);*/
map = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
/* This is what generates the SIGBUS. */
*map = 0;
}
Бежать с:
gcc -std=c99 main.c -lrt
./a.out
Протестировано в Ubuntu 14.04.
POSIX описывает SIGBUS как:
Доступ к неопределенной части объекта памяти.
Спецификация mmap говорит, что:
Ссылки в пределах диапазона адресов, начинающиеся с pa и продолжающиеся для длинных байтов до целых страниц после конца объекта, должны привести к доставке сигнала SIGBUS.
И shm_open говорит, что генерирует объекты размером 0:
Объект общей памяти имеет нулевой размер.
Таким образом, *map = 0мы касаемся конца выделенного объекта.
Нераспределенный доступ к памяти стека в ARMv8 aarch64
Это было упомянуто в: Что такое ошибка шины? для SPARC, но здесь я приведу более воспроизводимый пример.
Все, что вам нужно, это отдельная программа aarch64:
.global _start
_start:
asm_main_after_prologue:
/* misalign the stack out of 16-bit boundary */
add sp, sp, #-4
/* access the stack */
ldr w0, [sp]
/* exit syscall in case SIGBUS does not happen */
mov x0, 0
mov x8, 93
svc 0
Затем эта программа вызывает SIGBUS на Ubuntu 18.04 aarch64, ядре Linux 4.15.0 на сервере ThunderX2 .
К сожалению, я не могу воспроизвести его в пользовательском режиме QEMU v4.0.0, я не уверен почему.
Неисправность , как представляется, по желанию и контролируются SCTLR_ELx.SAи SCTLR_EL1.SA0полями, я обобщил связанные документы немного дальше здесь .
Я полагаю, что ядро вызывает SIGBUS, когда приложение демонстрирует смещение данных на шине данных. Я думаю, что, поскольку большинство [?] Современных компиляторов для большинства процессоров дополняют / выравнивают данные для программистов, проблемы выравнивания в прошлом (по крайней мере) смягчаются, и, следовательно, в наши дни SIGBUS не видят слишком часто (AFAIK).
От: Здесь
Вы также можете получить SIGBUS, если по какой-то причине невозможно вставить кодовую страницу.
Один классический случай ошибки шины возникает в некоторых архитектурах, таких как SPARC (по крайней мере, некоторые SPARC, возможно, это было изменено), когда вы делаете неправильный доступ. Например:
unsigned char data[6];
(unsigned int *) (data + 2) = 0xdeadf00d;Этот фрагмент кода пытается записать 32-разрядное целочисленное значение 0xdeadf00dв адрес, который (скорее всего) не выровнен должным образом, и сгенерирует ошибку шины на архитектурах, которые «разборчивы» в этом отношении. Intel x86, кстати, не такая архитектура, она позволила бы доступ (хотя и выполнял его медленнее).
Конкретный пример ошибки шины, с которой я только что столкнулся при программировании C на OS X:
#include <string.h>
#include <stdio.h>
int main(void)
{
char buffer[120];
fgets(buffer, sizeof buffer, stdin);
strcat("foo", buffer);
return 0;
}В случае, если вы не помните, документы strcatдобавляют второй аргумент к первому, изменяя первый аргумент (переверните аргументы, и все работает нормально). В Linux это дает ошибку сегментации (как и ожидалось), но в OS X это дает ошибку шины. Зачем? Я действительно не знаю.
Это зависит от вашей ОС, процессора, компилятора и, возможно, других факторов.
В общем, это означает, что шина ЦП не смогла выполнить команду или столкнулась с конфликтом, но это может означать целый ряд вещей, зависящих от среды и выполняемого кода.
-Адам
Обычно это означает неприсоединенный доступ.
Попытка получить доступ к памяти, которая физически отсутствует, также приведет к ошибке шины, но вы не увидите этого, если используете процессор с MMU и операционную систему, которая не глючит, потому что у вас не будет никаких -существующая память сопоставлена с адресным пространством вашего процесса.
Я получал ошибку шины, когда корневой каталог был на 100%.
Причиной ошибки шины в Mac OS X было то, что я попытался выделить около 1 МБ в стеке. Это хорошо работало в одном потоке, но при использовании openMP это приводит к ошибке шины, потому что Mac OS X имеет очень ограниченный размер стека для неосновных потоков .
Я согласен со всеми ответами выше. Вот мои 2 цента относительно ошибки шины:
Ошибка BUS не должна возникать из инструкций в коде программы. Это может произойти, когда вы запускаете двоичный файл и во время выполнения двоичный файл изменяется (перезаписывается сборкой или удаляется и т. Д.).
Проверка, так ли это:
Простой способ проверить, является ли это причиной, — запустить запущенные экземпляры одного и того же двоичного файла и запустить сборку. Оба запущенных экземпляра вылетят с SIGBUSошибкой вскоре после завершения сборки и заменят двоичный файл (тот, который в данный момент запущен обоими экземплярами)
Основная причина:
это происходит потому, что ОС меняет страницы памяти, и в некоторых случаях двоичный файл может загружаться не полностью в память, и эти сбои происходят, когда ОС пытается извлечь следующую страницу из того же двоичного файла, но двоичный файл изменился с момента последнего прочитай это.
Чтобы добавить к ответу blxtd выше, также возникают ошибки шины, когда ваш процесс не может попытаться получить доступ к памяти определенной «переменной» .
for (j = 0; i < n; j++) {
for (i =0; i < m; i++) {
a[n+1][j] += a[i][j];
}
}Заметили « непреднамеренное » использование переменной «i» в первом «цикле for»? Вот что в этом случае вызывает ошибку шины.
Я только что обнаружил, что на процессоре ARMv7 вы можете написать некоторый код, который выдает ошибку сегментации в неоптимизированном состоянии, но при компиляции с -O2 выдает ошибку шины (оптимизируйте больше).
Я использую кросс-компилятор GCC ARM gnueabihf из Ubuntu 64 бит.
Типичное переполнение буфера, которое приводит к ошибке шины,
{
char buf[255];
sprintf(buf,"%s:%sn", ifname, message);
}Здесь, если размер строки в двойных кавычках («») больше размера буфера, это дает ошибку шины.
Модератор: Модераторы разделов
-
simulacrum`
- Сообщения: 70
- ОС: openSUSE 11.1
Re: Kdevelop вываливается выдавая «ошибку шины»
Сообщение
simulacrum` » 17.12.2007 02:32
simulacrum@simulacrum:~/Install> gdb kdevdesigner
GNU gdb 6.6.50.20070726-cvs
Copyright © 2007 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type «show copying» to see the conditions.
There is absolutely no warranty for GDB. Type «show warranty» for details.
This GDB was configured as «i586-suse-linux»…
(no debugging symbols found)
Using host libthread_db library «/lib/libthread_db.so.1».
(gdb) r
Starting program: /opt/kde3/bin/kdevdesigner
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 0xb69ce8e0 (LWP 29672)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
—Type <return> to continue, or q <return> to quit—
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
—Type <return> to continue, or q <return> to quit—r
(no debugging symbols found)
(no debugging symbols found)
Program received signal SIGBUS, Bus error.
[Switching to Thread 0xb69ce8e0 (LWP 29672)]
0xb7f9554d in ?? () from /lib/ld-linux.so.2
1
1
Добрый день. Возникла проблема с VLC: плеер не стартует. Выводит сообщение «Ошибка шины» и завершается. Пробовал переустанавливать, ставить разные версии, ночнушки — все одно и тоже.
При установке, после обработки триггеров для vlc-nox, выводит сообщение
bus error
WARNING: Regenerating VLC plugin cache failed.
Please run 'vlc-cache-gen /usr/lib/vlc/plugins' manually
Пробовал этой рекомендации последовать, однако запуск vlc-cache-gen вызывает все ту же ошибку шины.
Я, к сожалению, не гуру линукса, поэтому не знаю, какую информацию ещё необходимо предоставить…
Железо:
Нетбук Packard Bell Dot SE на Intel Atom N450, 2 гига, обычный HDD, интегрированная графика.
Система Linux Mint 18 Cinnamon 64-bit
Cinnamon 3.0.7, Linux 4.4.0-21-generic.
Спасибо за любую помощь.
В конце концов, кажется, это были кабели.
Следуя предложению в отчете об ошибке, я заменил кабель SATA, использовал другой разъем питания SATA от моего источника питания (возможный виновник недостаточное питание) и убедился, что кабель SATA не был рядом другие силовые кабели (возможны электрические помехи от других, особенно силовых, кабелей).
Теперь он отлично работает.
С тех пор я вставил оригинальный кабель SATA, и он все еще работает. Я скоро переключу кабели питания и попробую повесить кабель SATA рядом с другими кабелями питания … Вероятно, кабель SATA был либо смещен, либо возникло плохое соединение из-за влажности или чего-то подобного.
ответ дан jpat827
12.01.2020, 02:25
Ссылка