Bug 9988

Summary: files corruption on >2.6.14-std26-smp-alt5
Product: Sisyphus Reporter: Konstantin Pavlov <thresh>
Component: kernel-image-std-smpAssignee: Sergey Vlasov <vsu>
Status: CLOSED FIXED QA Contact: qa-sisyphus
Severity: critical    
Priority: P2 CC: ldv, mike, silicium
Version: unstable   
Hardware: all   
OS: Linux   
Attachments:
Description Flags
dmesg with mem=3300M
none
lspci
none
lsmod none

Description Konstantin Pavlov 2006-09-12 15:08:06 MSD 
"портятся" файлы на / разделе с ext3fs , забиваются мусором вида ^@^@^@^@^@^@^@
при использовании ядер > чем 2.6.14-std26-smp-alt5.
проявляется на: 2.6.14-vs26-smp-alt5, 2.6.16-std26-smp-alt4,
2.6.16-std26-smp-alt7, 2.6.16-std26-smp-alt9.
не проявляется на 2.6.14-std26-smp-alt5.

sisyphus x86_64, dual xeon 3.0ghz, мать supermicro X6DHE-XB, 4G памяти.
/ лежит на raid1 сделанном с 3ware 8006-2LP.

кажется, помогает загрузиться с mem=3300M.
Comment 1 Konstantin Pavlov 2006-09-12 15:09:28 MSD 
Created attachment 1622 [details]
dmesg with mem=3300M
Comment 2 Konstantin Pavlov 2006-09-12 15:10:47 MSD 
Created attachment 1623 [details]
lspci
Comment 3 Konstantin Pavlov 2006-09-12 15:11:10 MSD 
Created attachment 1624 [details]
lsmod
Comment 4 Sergey Vlasov 2006-09-12 17:15:20 MSD 
На всякий случай ещё можно попробовать запретить загрузку модуля e752x_edac
(например, занесением его в /etc/hotplug/blacklist) и проверить поведение
системы в таком варианте с полным объёмом памяти (без mem=3300M).  По крайней
мере в случае, если ошибки выявляются достаточно быстро.

Хотя всё-таки подозрение на swiotlb...
Comment 5 Sergey Vlasov 2006-12-20 20:08:15 MSK 
В 2.6.18 это не починилось?
Comment 6 Konstantin Pavlov 2006-12-20 23:47:05 MSK 
К сожалению, у меня больше нет доступа к машине.
Comment 7 Sergey Vlasov 2008-02-27 18:33:38 MSK 
Похоже, проблема действительно существует, и наблюдается в 2.6.18:

http://bugzilla.kernel.org/show_bug.cgi?id=7246
Comment 8 Michael Shigorin 2008-07-06 15:39:57 MSD 
Выдрано из последнего фрагмента
(в upstream закрыто как CLOSED PATCH_ALREADY_AVAILABLE):

The 3w-xxxx driver calling pci_map_sg() with sc_data_direction ==
DMA_BIDIRECTIONAL caused data corruption when going through swiotlb.c, on EM64T
with 4GB or higher of RAM.  AMD64 systems using IOMMU were never affected.

This problem doesn't exist in the 3w-xxxx driver in kernels 2.6.23 and higher.
The reason is the 'scsi data buffer accessors' patches removed most instances 
of scsi drivers calling pci_map_sg() and replaced them with scsi_dma_map().

This corrected the problem of the 3w-xxxx driver over-riding the default
sc_data_direction that was causing data corruption with EM64T systems with 
4GB+ RAM.

If you need a driver update for an older kernel to fix this issue, please go to
www.3ware.com, however no driver patch to 3w-xxxx needs to be sent to the
kernel tree to fix this issue.

Применительно к 2.6.18-alt даже не знаю, FIXED это или WONTFIX.
Comment 9 Michail Yakushin 2008-07-06 21:47:17 MSD 
Видимо всё таки фиксед
Comment 10 Konstantin Pavlov 2008-07-07 01:06:39 MSD 
Закрываю.  И советую всем, кто натолкнется -- бежать и выкидывать 8 серию с обменом на 9ки.