Port-xen archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: amd64 domU panic w/ raidframe re-write
On Thu, Feb 07, 2008 at 12:23:09AM -0600, jakllsch%kollasch.net@localhost wrote:
> Hi,
>
> I'm running raidframe in a amd64 domU. I had had to do a hard reboot
> because I did something stupid in the linux dom0 (xm mem-set 0 0).
>
> Anyway, now when I go to rebuild the parity on the RAID1 array:
>
>
> # raidctl -P raid0
> /dev/rraid0d: Parity status: DIRTY
> /dev/rraid0d: Initiating re-write of parity
> panic: kernel diagnostic assertion "seg <= BLKIF_MAX_SEGMENTS_PER_REQUEST"
> failed: file "/local/jakllsch/nbsd50/src/sys/arch/xen/xen/xbd_xenbus.c", line
> 759
> Stopped in pid 0.20 (system) at netbsd:breakpoint+0x1: ret
> breakpoint() at netbsd:breakpoint+0x1
> __kernassert() at netbsd:__kernassert+0x2d
> xbdstart() at netbsd:xbdstart+0x4e8
> dk_start() at netbsd:dk_start+0x3f
> dk_strategy() at netbsd:dk_strategy+0x115
> spec_strategy() at netbsd:spec_strategy+0x5e
> VOP_STRATEGY() at netbsd:VOP_STRATEGY+0x26
> rf_DispatchKernelIO() at netbsd:rf_DispatchKernelIO+0x1ef
> rf_DiskReadFuncForThreads() at netbsd:rf_DiskReadFuncForThreads+0xd7
> FireNodeList() at netbsd:FireNodeList+0x76
> rf_FinishNode() at netbsd:rf_FinishNode+0x306
> rf_DispatchDAG() at netbsd:rf_DispatchDAG+0x12d
> rf_VerifyParityRAID1() at netbsd:rf_VerifyParityRAID1+0x4c4
> rf_VerifyParity() at netbsd:rf_VerifyParity+0x66
> rf_RewriteParity() at netbsd:rf_RewriteParity+0xac
> rf_RewriteParityThread() at netbsd:rf_RewriteParityThread+0x41
> ds 0x5
> es 0xa97c
> fs 0x10d8
> gs 0xaa4f
> rdi 0
> rsi 0xd
> rbp 0xffffa0001247f6c0
> rbx 0x1
> rdx 0
> rcx 0
> rax 0x1
> r8 0xffffffff80581520 cpu_info_primary
> r9 0
> r10 0xffffa0001247f4e0
> r11 0xffffffff80381680 xenconscn_putc
> r12 0x100
> r13 0xffffffff804710d8 copyright+0x8c118
> r14 0xffffa000122f45f0
> r15 0x5000
> rip 0xffffffff8036abb9 breakpoint+0x1
> cs 0xe030
> rflags 0x246
> rsp 0xffffa0001247f5c8
> ss 0xe02b
> netbsd:breakpoint+0x1: ret
> db>
>
> This kernel is 4.99.52 from approximately a week ago.
>
> Is this because my sectPerSU is 128, or 64KiB,
> which is greater than MAXPHYS in a domU?
Yes. I think I have a PR open about "RAIDframe can send requests larger than
MAXPHYS", or something like that
>
> And how hard would it be to have a 64KiB
> MAXPHYS Just Work?
quite hard. If we did it, we could just as well do it at some upper
layer, and get rid of MAXPHYS completely (and have each device advertize their
MAXPHYS instead). I think it's the way to go, for other reasons: all but
legacy ESDI drives would probably be happier with MAXPHYS of 128k, and
SCSI and SATA would probably be much faster with a MAXPHYS of 256 or 512k.
I had proposed a google SOC on this, but it didn't get selected.
--
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
NetBSD: 26 ans d'experience feront toujours la difference
--
Home |
Main Index |
Thread Index |
Old Index