Bug#389232: linux-image-2.6-amd64: mounting xfs filesystem causes kernel oops
On Sun, Sep 24, 2006 at 10:19:07PM +0200, Dan Ohnesorg wrote:
> Dne Sun, Sep 24, 2006 at 09:23:15PM +0200, Oleg Verych napsal:
>
> > Let's add XFS team in CC.
>
> There isn't
Yes, my MUA...
>
> > On 2006-09-24, Dan Ohnesorg <bugs@ohnesorg.cz> wrote:
> > > Package: linux-image-2.6-amd64
> > > Version: 2.6.17+2
> > > Severity: critical
> > > Justification: breaks the whole system
> >
> > More details, please.
> >
> > What happend before this boot?
> >
> > Why ext3 is recovering?
>
> The system was installed as 32 bit system, fresh install of debian etch,
> some week ago. (I remember, that beta3 of installer was only one day old).
> Runned good, but I have decided to migrate to 64 bit. All drives except xfs
> one are reformatted, only xfs has been kept untouched. Even if the xfs was
> probably clean unmounted, installer had some problem with mounting xfs into
> /target. So I deciced not to mount xfs automatically. After first boot,
> while mounting xfs manually the kernel oopsed and was not able to shutdown
> correctly, so the next boot was unclean and the ext3 (/) has to be
> recovered. I have made the bugreport after second unsecssful boot.
>
> The instalation was made by nightly snapshoot of installer from 24-Sep-2006
> 02:33. I didn't use beta3, becouse beta 3 is missing xfs libs.
>
> > > raid1: raid set md1 active with 4 out of 4 mirrors
> > > EXT3-fs: INFO: recovery required on readonly filesystem.
> > > EXT3-fs: write access will be enabled during recovery.
> > > kjournald starting. Commit interval 5 seconds
> >
> > And why XFS does ?
>
> Don't know exactly, as written above.
>
> > In upstream there are very hidden bugs with XFS, which are very hard
> > to find, because they are rare and are showed on big machines:
> > huge RAM, many CPUs. Maybe you can help.
> >
> > (s)ata + xfs bug: <http://permalink.gmane.org/gmane.linux.kernel/446612>
> > devmaper + xfs bug: <http://permalink.gmane.org/gmane.linux.kernel/444139>
>
> The problem was solved by using my own kernel, 2.6.18.
Well, that means you've cathed this (git commit):
b2ea401bac39e75ebb64038609ed22efbc799905
Maybe it's worth to ask to be in next 2.6.17-stable ?
Reply to: