lkml.org 
[lkml]   [2005]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 2.6.13 (was 2.6.11.11) and rsync oops (SATA or NFS related?)
Date
Kalin KOZHUHAROV wrote:
> Kalin KOZHUHAROV wrote:
>
>> Kalin KOZHUHAROV wrote:
>>
>>> Hi, there. Long time no posting - didn't have kernel problems for
>>> long time :-)
[snip]
But I really hate when my "production boxes" turn into development ones...

>>> Although it does not seem very related to the drive, that is the
>>> only recent change in hardware, in software: udev . The machine
>>> (MB: A7N8X Deluxe) was working stable for 6 months with a few
>>> restarts.

A closer examination of the drive:
(Model=ST3300831AS, FwRev=3.03, SerialNo=3NF07KA1 )
and why is it so slow revealed that it was running not in UDMA.

According to the specs:
http://www.seagate.com/support/disc/manuals/sata/cuda72008_sata_pm.pdf
it supports (page 13 of 50):
PIO modes 0–4
Multiword DMA modes 0–2
Ultra DMA modes 0–6

but hdparm gives:
# hdparm -i /dev/hdg |grep modes
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 *udma2

Where are udma3-6 gone?

Does anyone have this particular model (Barracuda 7200.8) and do you have it working properly?

Issuing `hdparm -d1 -X udma2` was accepted and looks good.
Continuing to test like that...

My other drive (on the same controller):
Model=WDC WD360GD-00FLA0, FwRev=21.08U21, SerialNo=WD-WMAKE1163111

# hdparm -i /dev/hde |grep modes
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6

The controller:
# lspci -s 01:0b -vv
0000:01:0b.0 RAID bus controller: Silicon Image, Inc. (formerly CMD Technology Inc) SiI 3112 [SATALink/SATARaid] Serial ATA Controller (rev 02)
Subsystem: Silicon Image, Inc. (formerly CMD Technology Inc) SiI 3112 SATARaid Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32, cache line size 01
Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at a400 [size=1024M]
Region 1: I/O ports at a800 [size=4]
Region 2: I/O ports at ac00 [size=8]
Region 3: I/O ports at b000 [size=4]
Region 4: I/O ports at b400 [size=16]
Region 5: Memory at e1001000 (32-bit, non-prefetchable) [size=512]
Expansion ROM at 00080000 [disabled]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-

>> OK, I upgraded to the latest 2.6.13 kernel and still got (similar?) oops.
>>
>> Looking again at it it might be NFS (using v4 recently) related.
>
>
> After stopping nfs (both v3 and v4) and rebooting, I could finish the
> required 170GB rsync without more oopses. But I am still not
> convinced whether this is a nfs issue or just I am being lucky this
> time. Will keep on eye on the machine and report here again.

Got one total oops, even no logs were written to disk.
Seems that rsync-ing huge amounts of data (200 GB in *many* small files) streses the system too much.

> / When nobody answers, try answering yourself :-| /
Second on that!

Kalin.

--
|[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
+-> http://ThinRope.net/ <-+
|[ ______________________ ]|

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-09-06 10:33    [W:0.123 / U:0.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site