Messages in this thread | | | From | Kalin KOZHUHAROV <> | Subject | Re: 2.6.13 (was 2.6.11.11) and rsync oops (SATA or NFS related?) | Date | Tue, 06 Sep 2005 17:24:35 +0900 |
| |
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/
| |