On Saturday 01 August 2009 12:07:12 Michael Buesch wrote:
> On Saturday 01 August 2009 11:04:11 Milan Broz wrote:
> > Herbert Xu wrote:
> > > On Fri, Jul 31, 2009 at 10:54:45PM +0200, Michael Buesch wrote:
> > >> [15577.988608] NIP [c00b8034] .mempool_alloc+0x74/0x1a0
> > >> [15577.988614]
On Saturday 01 August 2009 11:04:11 Milan Broz wrote:
> Herbert Xu wrote:
> > On Fri, Jul 31, 2009 at 10:54:45PM +0200, Michael Buesch wrote:
> >> [15577.988608] NIP [c00b8034] .mempool_alloc+0x74/0x1a0
> >> [15577.988614] LR [c0139bdc] .bio_alloc_bioset+0x4c/0x130
> >> [15577.98861
Herbert Xu wrote:
> On Fri, Jul 31, 2009 at 10:54:45PM +0200, Michael Buesch wrote:
>> [15577.988608] NIP [c00b8034] .mempool_alloc+0x74/0x1a0
>> [15577.988614] LR [c0139bdc] .bio_alloc_bioset+0x4c/0x130
>> [15577.988616] Call Trace:
>> [15577.988619] [c001f022fb60] [c001f02
On Fri, Jul 31, 2009 at 10:54:45PM +0200, Michael Buesch wrote:
> The following oops happened while doing an mke2fs -j on a luks mapping.
> I think (I'm not entirely sure) that it was triggered by running the "sync"
> command
> simultaneously to the mke2fs. Both sync and mke2fs are stuck in D stat