On Monday February 23, P.Luptak@sh.cvut.cz wrote:
Hello,
issue http://www.spinics.net/lists/lvm/msg10322.html could be still present
in the current 2.6.3 kernel. I am able to repeat the conditions to halt the
2.6.3 kernel (using mkfs.ext3 on RAID device):
To be fair, your subject should say that
SW RAID5 + high memory + loop device freezes 2.6.3 kernel
^^^^^^^^^^^^^^
Would you be able to try the same tes without using "loop" in the
middle and see what happens?
The trace you sent:
Feb 23 02:52:12 psilocybus kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000008
Feb 23 02:52:12 psilocybus kernel: printing eip:
Feb 23 02:52:12 psilocybus kernel: f9885205
Feb 23 02:52:12 psilocybus kernel: *pde = 00000000
Feb 23 02:52:12 psilocybus kernel: Oops: 0000 [#1]
Feb 23 02:52:12 psilocybus kernel: CPU: 0
Feb 23 02:52:12 psilocybus kernel: EIP: 0060:[<f9885205>] Tainted: PF
Feb 23 02:52:12 psilocybus kernel: EFLAGS: 00010246
Feb 23 02:52:12 psilocybus kernel: EIP is at make_request+0x5/0x210 [raid5]
Feb 23 02:52:12 psilocybus kernel: eax: f10e2f2b ebx: f6631800 ecx: f7fe9040 edx: 00001000
Feb 23 02:52:12 psilocybus kernel: esi: 00000008 edi: c644dbc0 ebp: 025c0e08 esp: c1b8bcd0
seems to suggest that %esi is being dereferenced at make_request+0x5,
but when I disassemble my raid5.o, it doesn't.
I tried disassembling the code:
Feb 23 02:52:12 psilocybus kernel:
Feb 23 02:52:12 psilocybus kernel: Code: a7 c0 09 b6 d3 db 66 06 71 67 67 d7 32 47 2a 92 23 22 ee b1
but that just produced nonsense.
Could you
gdb raid5.o
disassemble make_request
and send me the output please.
NeilBrown
Neil Brown [off-list ref] wrote:
quoted
Hello,
> issue http://www.spinics.net/lists/lvm/msg10322.html could be still present
> in the current 2.6.3 kernel. I am able to repeat the conditions to halt the
> 2.6.3 kernel (using mkfs.ext3 on RAID device):
To be fair, your subject should say that
SW RAID5 + high memory + loop device freezes 2.6.3 kernel
^^^^^^^^^^^^^^
hm, yes. And the loop code which was involved here was removed from the
kernel last week, so it's a bit academic.
Retest on current 2.6.3-bk or 2.6.3-mm3 please.
On Sun, Feb 22, 2004 at 09:30:11PM -0800, Andrew Morton wrote:
Neil Brown [off-list ref] wrote:
quoted
quoted
Hello,
> issue http://www.spinics.net/lists/lvm/msg10322.html could be still present
> in the current 2.6.3 kernel. I am able to repeat the conditions to halt the
> 2.6.3 kernel (using mkfs.ext3 on RAID device):
To be fair, your subject should say that
SW RAID5 + high memory + loop device freezes 2.6.3 kernel
^^^^^^^^^^^^^^
hm, yes. And the loop code which was involved here was removed from the
kernel last week, so it's a bit academic.
Retest on current 2.6.3-bk or 2.6.3-mm3 please.
I tried 2.6.3-bk4 and seems it works without problems :)
I'm going to copy about 300 GB data to this cryptoloop/RAID5 and report the
eventual bugs....
Pavol
--
_____________________________________________________________________________
[wilder@hq.sk] [http://trip.sk/wilder/] [talker: ttt.sk 5678] [ICQ: 133403556]
Neil,
Currently, the device size calculation is not correct when hot-adding
devices to arrays with non-persistent superblocks. Device size is always
calculated as if there were a physical superblock on every device. The
attached simple change to hot_add_disk() fixes the problem.
Thanks,
Paul
The attached patch makes sure that resync/recovery get aborted (and
status recorded correctly) when there are no spare drives left (due to
the failure of a spare during a resync). Previously, if a spare failed
during a resync, the resync would continue until completed (and would
appear to be successful).
Also, there was an erroneous usage of master_bio->bi_bdev field (which
is not always properly set) that has been changed to the simpler
comparison vs. r1_bio->read_disk (as is done in raid1_end_request). I
think Neil has already addressed this issue in another patch that has
been pushed to Andrew...
Thanks,
Paul