Re: ext3 oops (probably I/O congestion/starvation related), alreadysolved?

[Roberto Nibali]

Hello Jens,

Thanks for your reply.

> Just to be on the safe side, have you reproduced it without?

Nope, I would first like to backup the data since this trace got me 
pretty scared and I care about the data on this disk. So I bought a 
DVD-R burner and I'm now happily doing my 160GB of backup.

> Just
> because nvidia doesn't show up in the trace, doesn't mean it hasn't
> corrupted memory elsewhere.

Fair enough.

> 00200200 is the list deletion poison, double remove of a list and in
> this case the timer base. That's pretty bad news.
>
> So please do try and reproduce without the nvidia module.

I will try, for sure and I'll post back my results if I can make it oops 
again.. However I don't know how to reproduce it. I showed up once or 
twice during high I/O and while I was writing to and reading from disk 
over ieee1394. Could it also be a bad cable? The I/O is also dog slow 
when writing to disk, reading is like 15 MBytes/s.

> This is also a list related issue:
>
>         if (!list_empty(&sbi->s_orphan))
>                 dump_orphan_list(sb, sbi);
>         J_ASSERT(list_empty(&sbi->s_orphan));

I'll also try a new firewire cable, since most of the times (in my 
experience) the cable has been the source of all problems. Normally the 
disk gets only remounted RO during deletion of files (this is a really 
irritating thing right now, I can't delete my files over ieee1394) which 
seems to prevent this kind of oops.

Thanks and best regards,
Roberto Nibali, ratz
--
echo 
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/