Re: SMP vs. RAIDframe?

[Holger Weiss <lists%jhweiss.de@localhost>]

* Holger Weiss <lists%jhweiss.de@localhost> [2008-09-29 13:23]:
> * Martin Husemann <martin%duskware.de@localhost> [2008-09-28 17:35]:
> > And when you generate heavy disk I/O it locks up?
> 
> That's what I thought, but then I noticed that in _this_ case (heavy
> disk I/O while only one RAIDframe component is active), the system does
> not freeze completely.  That is, it still pings and forwards IP packets,
> but neither the SSHd nor the other daemons I tried send any data, and
> serial console I/O is frozen.  (However, if I reconstruct the second
> RAIDframe component or rewrite the parity, the system locks up
> completely within a few minutes.  So, this might be a separate issue.)
> 
> I have no time right now, I'll try to gather more useful information
> next weekend.

Well, I'm not much wiser, yet.  I'm able to reproduce the issues I
described pretty reliably, though:

- Booting into GENERIC.MP always leads to RAIDframe complaining about
  dirty parity.

- Attempting to rewrite the parity or to reconstruct a mirror component
  while running GENERIC.MP leads to a complete lock-up (usually within a
  few seconds) without me being able to BREAK into DDB.

- Running GENERIC.MP with only a single active mirror component seems to
  work fine until I generate somewhat heavy disk I/O.  For example,
  running build.sh on an empty $OBJDIR usually leads to a "freeze" while
  creating the object directories.  In this case, I can break into DDB
  and get traces such as the following (typewritten from the serial
  terminal, hopefully without typos):

---------- 8< ---------------------------------------------- 8< ----------
sab_intr(0, 0, 10b38058, 1d74, 0, 39) at netbsd:sab_intr+0x48
intr_biglock_wrapper(6365580, 0, e0017ed0, 0, 141b000, 18c6800) at 
netbsd:intr_biglock_wrapper+0x10
sparc_interrupt(0, 13752fd8, 2139, 0, 101, 0) at netbsd:sparc_interrupt+0x1ec
mutex_vector_enter(189ebf0, 11c5b400, 0, 0, 0, 13752fd8) at 
netbsd:mutex_vector_enter+0x28c
pmap_extract(12193680, 41162000, 0, 137531a8, 0, 4) at netbsd:pmap_extract+0x18
uvm_fault_internal(0, 41162000, 0, 13753228, 3, 41162000) at 
netbsd:uvm_fault_internal+0x43c
data_access_fault(137534d0, 30, 100a184, 41169af8, 41168000, 400) at 
netbsd:data_access_fault+0x15c
?(10bc8000, 41168000, 1ff8, 13750000, 100a218, 18189f0) at 0x1008708
copyout_vmspace(11e48750, 10bc8000, 41168000, 2000, 0, d) at 
netbsd:copyout_vmspace+0x5c
uiomove(10bc8000, 2000, 13753bf0, 0, 101, 18c6800) at netbsd:uiomove+0xa8
ubc_uiomove(0, 13753bf0, 2139, 0, 101, 0) at netbsd:ubc_uiomove+0x94
ffs_read(0, 1, 8000, 13753a48, 41015d60, 0) at netbsd:ffs_read+0x378
VOP_READ(16ffe0c0, 13753bf0, 0, 125cf3c0, 4073c820, 0) at netbsd:VOP_READ+0x6c
vn_read(132eff40, 132eff40, 13753bf0, 125cf3c0, 1, 0) at netbsd:vn_read+0x88
dofileread(16, 132eff40, 41168000, 8000, 1d, 1) at netbsd:dofileread+0x60
sys_read(1d, 13753dc0, 13753e00, ffffffffffff6868, 4020a800, 18189f0) at 
netbsd:sys_read+0x60
syscall_plain(13753ed0, 3, 40e3d124, 40e3d128, 0, 13753dc0) at 
netbsd:syscall_plain+0x110
?(1d, 41168000, 8000, 1, 400, 8000) at 0x1008c68
---------- 8< ---------------------------------------------- 8< ----------

Holger