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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux