xfs
[Top] [All Lists]

Re: problems booting/recovery after crash (xfs cvs)

To: "Jeffrey E. Hundstad" <jeffrey.hundstad@xxxxxxxx>
Subject: Re: problems booting/recovery after crash (xfs cvs)
From: Mihai RUSU <dizzy@xxxxxxxxx>
Date: Wed, 18 Jun 2003 02:27:19 +0300 (EEST)
Cc: Linux XFS List <linux-xfs@xxxxxxxxxxx>
In-reply-to: <3EEF7271.30500@mnsu.edu>
Sender: linux-xfs-bounce@xxxxxxxxxxx
Hi

Thanks for the help but I am using DAC960 Mylex RAID controller (I dont
even compile ATA/IDE support in kernel).

On Tue, 17 Jun 2003, Jeffrey E. Hundstad wrote:

> Are you using an IDE controller.
>
> If you are using:
> CONFIG_BLK_DEV_PDC202XX_OLD=y
> or
> CONFIG_BLK_DEV_PDC202XX_NEW=y
>
> be sure to read linux/drivers/ide/pci/pdc202xx_old.c:
>  *  Promise Ultra33 cards with BIOS v1.20 through 1.28 will need this
>  *  compiled into the kernel if you have more than one card installed.
>  *  Note that BIOS v1.29 is reported to fix the problem.  Since this is
>  *  safe chipset tuning, including this support is harmless
>
> If you have the newer bios use _NEW.  If you have a bios before 1.28 you
> need _OLD.  I can *confirm* that if you DO NOT follow this advice you
> will get oopses and hangs on your machines when XFS (or any other disk
> i/o) is busy.
>
> BTW: I can also confim this was my problem earlier this month also.  <sigh>
> Thanks to those who helped me.
>
> --
> jeffrey hundstad
>
> Mihai RUSU wrote:
>
> >Hi
> >
> >After 2.4.21 kernel release I wanted to try it out on some of the machines
> >here.  For that I checked out CVS (SGI-XFS CVS-2003-06-16_05:00_UTC with
> >no debug enabled) compiled and booted. After 20 hours of uptime the
> >machine had to be rebooted hard (well ,that was actually a mistake but
> >thats not the point) by unplugging it. After power on, it booted until the
> >first "big" XFS filesystem recovery were it hanged (disk activity on that
> >fs stopped after some seconds). When I say big I mean a ~140 gb partition
> >(before that one, there was another XFS partitions which didnt had the
> >hanging problem but which is a lot smaller, 16gb, and also which has
> >internal journal different from the one were it hangs which has external
> >jurnal). I have tried many kernels from the lilo boot menu and no one
> >succeded except for the 2.4.9-34 kernel (contributed kernel from the 1.1
> >release dir). The kernels that I have tried and not succeded were
> >2.4.21-cvs (the version mentioned above) and 2.4.18-18SGI_XFS_1.2.0. I
> >also mention that all this kernels I have compiled them myself using gcc
> >2.95.3.
> >
> >Another strange thing is that in the kernel logs I couldnt find the boot
> >messages of the boot tries before that last one (2.4.9-34) that worked.
> >When 2.4.9-34 booted also gave me some interesting kernel logs:
> >
> >Jun 17 15:41:08 s1 kernel: Starting XFS recovery on filesystem:
> >dac960(48,9) (dev: 8/6)
> >Jun 17 15:41:08 s1 kernel: xfs_inotobp: xfs_imap()  returned an error 22
> >on dac960(48,9).  Returning error.
> >Jun 17 15:41:08 s1 kernel: xfs_iunlink_remove: xfs_inotobp()  returned an 
> >error
> >22 on dac960(48,9).  Returning error.
> >Jun 17 15:41:08 s1 kernel: xfs_inactive:  xfs_ifree() returned an error =
> >22 on dac960(48,9)
> >Jun 17 15:41:08 s1 kernel: xfs_force_shutdown(dac960(48,9),0x1) called
> >from line 1962 of file xfs_vnodeops.c.  Return address = 0xc01cf242
> >Jun 17 15:41:08 s1 kernel: I/O Error Detected.  Shutting down filesystem:
> >dac960(48,9)
> >Jun 17 15:41:08 s1 kernel: Please umount the filesystem, and rectify the
> >problem(s)
> >Jun 17 15:41:08 s1 kernel: Ending XFS recovery on filesystem: dac960(48,9)
> >(dev: 8/6)
> >
> >After 2.4.9-34 booted I rebooted the machine (software) and it booted
> >2.4.29-cvs just fine.
> >
> >Because I never had problems with that machine before (hardware problems)
> >and because it did it only on XFS recovery I presume its a XFS bug ?
> >
> >I would like to know what can I do to make sure it doesnt happen again.
> >Thanks :)
> >
> >----------------------------
> >Mihai RUSU
> >
> >Disclaimer: Any views or opinions presented within this e-mail are solely
> >those of the author and do not necessarily represent those of any company,
> >unless otherwise specifically stated.
> >
> >
> >
> >
>
>

----------------------------
Mihai RUSU

Disclaimer: Any views or opinions presented within this e-mail are solely
those of the author and do not necessarily represent those of any company,
unless otherwise specifically stated.


<Prev in Thread] Current Thread [Next in Thread>