Re: 2.6.13 (was 2.6.11.11) and rsync oops (SATA or NFS related?)

[Kalin KOZHUHAROV <kalin@thinrope.net>]

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/