Re: Vinum Spielereien

From: Oliver Lehmann <lehmann(at)ans-netz.de>
Date: Fri, 30 Jan 2004 23:14:37 +0100

Hi, hier nochmal die Infos

scbus1 on sym0 bus 0:
<SEAGATE ST11200N SUN1.05 9500> at scbus1 target 0 lun 0 (pass1,da1)
<SEAGATE ST31200N 8590> at scbus1 target 1 lun 0 (pass2,da2)
<SEAGATE ST31200N 8590> at scbus1 target 2 lun 0 (pass3,da3)
<SEAGATE ST31200N 8590> at scbus1 target 3 lun 0 (pass4,da4)
<Quantum VP32210 81HA> at scbus1 target 5 lun 0 (pass5,da5)
<NEC DSE2100S 0307> at scbus1 target 6 lun 0 (pass6,da6)

root(at)nudel backup> ls -1 /dev/da[1-9]*
/dev/da1
/dev/da1s1
/dev/da1s1c
/dev/da1s1d
/dev/da2
/dev/da2s1
/dev/da2s1c
/dev/da2s1d
/dev/da3
/dev/da3s1
/dev/da3s1c
/dev/da3s1d
/dev/da4
/dev/da4s1
/dev/da4s1c
/dev/da4s1d
/dev/da5
/dev/da5s1
/dev/da5s1c
/dev/da5s1d
/dev/da6
/dev/da6s1
/dev/da6s1c
/dev/da6s1d

RAID-5 ist oben, gemountet usw

Ok, nun das drive ab und ein touch in dem raid-mountpoint

(da4:sym0:0:3:0): lost device
(da4:sym0:0:3:0): Invalidating pack
vinum: lvmr5.p0.s3 is crashed by force
vinum: lvmr5.p0 is degraded
malloc() of "16" with the following non-sleepable locks held:
exclusive sleep mutex g_xup r = 0 (0xce2eccbc) locked @ /usr/src/sys/geom/geom_io.c:374
fatal:lvmr5.p0.s3 read error, block 4233 for 2048 bytes
lvmr5.p0.s3: user buffer block 12032 for 2048 bytes
d6: fatal drive I/O error, block 4233 for 2048 bytes
vinum: drive d6 is down
malloc() of "16" with the following non-sleepable locks held:
exclusive sleep mutex g_xup r = 0 (0xce2eccbc) locked @ /usr/src/sys/geom/geom_io.c:374
malloc() of "16" with the following non-sleepable locks held:
exclusive sleep mutex g_xup r = 0 (0xce2eccbc) locked @ /usr/src/sys/geom/geom_io.c:374
malloc() of "16" with the following non-sleepable locks held:
exclusive sleep mutex g_xup r = 0 (0xce2eccbc) locked @ /usr/src/sys/geom/geom_io.c:374
(da4:sym0:0:3:0): Synchronize cache failed, status == 0x4a, scsi status == 0x0
(da4:sym0:0:3:0): removing device entry
GEOM: destroy disk da4 dp=0xc2de7850

root(at)nudel tmp> camcontrol devlist
<SEAGATE ST11200N SUN1.05 9500> at scbus1 target 0 lun 0 (pass1,da1)
<SEAGATE ST31200N 8590> at scbus1 target 1 lun 0 (pass2,da2)
<SEAGATE ST31200N 8590> at scbus1 target 2 lun 0 (pass3,da3)
<Quantum VP32210 81HA> at scbus1 target 5 lun 0 (pass5,da5)
<NEC DSE2100S 0307> at scbus1 target 6 lun 0 (pass6,da6)

Jetzt drive wieder ran

root(at)nudel tmp> camcontrol rescan 1
Re-scan of bus 1 was successful

root(at)nudel tmp> camcontrol devlist
<SEAGATE ST11200N SUN1.05 9500> at scbus1 target 0 lun 0 (pass1,da1)
<SEAGATE ST31200N 8590> at scbus1 target 1 lun 0 (pass2,da2)
<SEAGATE ST31200N 8590> at scbus1 target 2 lun 0 (pass3,da3)
<SEAGATE ST31200N 8590> at scbus1 target 3 lun 0 (pass4,da4)
<Quantum VP32210 81HA> at scbus1 target 5 lun 0 (pass5,da5)
<NEC DSE2100S 0307> at scbus1 target 6 lun 0 (pass6,da6)

die devices unter /dev/ waren immer da, auch ohne Platte. syslog hat keine
weiteren Eintraege bekommen

root(at)nudel tmp> vinum ls
S lvmr5.p0.s0 State: up D: d3 Size: 1004 MB
S lvmr5.p0.s1 State: up D: d4 Size: 1004 MB
S lvmr5.p0.s2 State: up D: d5 Size: 1004 MB
S lvmr5.p0.s3 State: crashed D: d6 Size: 1004 MB
S lvmr1.p0.s0 State: up D: d1 Size: 2007 MB
S lvmr1.p1.s0 State: up D: d2 Size: 2007 MB
root(at)nudel tmp>

root(at)nudel tmp> vinum start lvmr5.p0.s3
Can't start lvmr5.p0.s3: Drive is down (5)
root(at)nudel tmp>

Wieso bekommt man das drive denn eigentlich nicht mehr gestartet?
Bzw. was muss man tun damit man es restartet bekommt? Anhand der
Tatsache das man es nach dem Boot gestartet bekommt => Wird das
device evtl nicht wieder richtig "angemeldet" bei vinum?

root(at)nudel tmp> vinum stop
Can't unload vinum: No such file or directory
root(at)nudel tmp>

root(at)nudel tmp> vinum start

Wie gehabt: Haenger... Ctrl+Alt+Esc

gdb> show all procs
bei vinum stand was von g_waitfor_event oder so aehnlich.
gdb> panic
[....]

nach dem reboot:

root(at)nudel tmp> gdb -k /usr/obj/i386-5.2/usr/src/sys/NUDEL/kernel.debug vmcore.1
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
panic: from debugger
panic messages:

---
panic: from debugger
cpuid = 0; 
boot() called on cpu#0
syncing disks, buffers remaining... 2204 2204 2204 2204 2204 2204 2204 2204 2204 2204 2204 2204 2204 2204 2204 2204 2204 2204 2204 2204 
giving up on 436 buffers
Uptime: 14m27s
Dumping 256 MB
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
Reading symbols from /boot/kernel/if_xl.ko...done.
Loaded symbols for /boot/kernel/if_xl.ko
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240             dumping++;
(kgdb) bt
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1  0xc051005b in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
#2  0xc051045d in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3  0xc044f6c2 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4  0xc044f622 in db_command (last_cmdp=0xc0704c00, cmd_table=0x0, aux_cmd_tablep=0xc06d0980, aux_cmd_tablep_end=0xc06d0984)
    at /usr/src/sys/ddb/db_command.c:346
#5  0xc044f765 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6  0xc0452765 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:73
#7  0xc0666f1c in kdb_trap (type=3, code=0, regs=0xce2d1c0c) at /usr/src/sys/i386/i386/db_interface.c:171
#8  0xc067c598 in trap (frame=
      {tf_fs = 24, tf_es = -1066794992, tf_ds = 16, tf_edi = -1065297472, tf_esi = -1065393248, tf_ebp = -835904424, tf_isp = -835904456, tf_ebx = 0, tf_edx = 0, tf_ecx = 32, tf_eax = 38, tf_trapno = 3, tf_err = 0, tf_eip = -1067027931, tf_cs = 8, tf_eflags = 642, tf_esp = -1066624422, tf_ss = -1066627844})
    at /usr/src/sys/i386/i386/trap.c:580
#9  0xc0668968 in calltrap () at {standard input}:94
#10 0xc065f60e in scgetc (sc=0xc080d9c0, flags=2) at /usr/src/sys/dev/syscons/syscons.c:3346
#11 0xc065ad00 in sckbdevent (thiskbd=0xc07f4920, event=0, arg=0xc080d9c0) at /usr/src/sys/dev/syscons/syscons.c:633
#12 0xc064aa8c in atkbd_intr (kbd=0xc07f4920, arg=0x0) at /usr/src/sys/dev/kbd/atkbd.c:460
#13 0xc0684cc1 in atkbd_isa_intr (arg=0x0) at /usr/src/sys/isa/atkbd_isa.c:176
#14 0xc04fc4f2 in ithread_loop (arg=0xc2ca8700) at /usr/src/sys/kern/kern_intr.c:544
#15 0xc04fb4a4 in fork_exit (callout=0xc04fc360 <ithread_loop>, arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:793
(kgdb) 
Gut.. nicht wirklich brauchbar. Wie komme ich denn zu einem Dump mit Infos
zu dem Problem?
root(at)nudel tmp> vinum ls
S lvmr5.p0.s0           State: up       D: d3           Size:       1004 MB
S lvmr5.p0.s1           State: up       D: d4           Size:       1004 MB
S lvmr5.p0.s2           State: up       D: d5           Size:       1004 MB
S lvmr5.p0.s3           State: crashed  D: d6           Size:       1004 MB
S lvmr1.p0.s0           State: up       D: d1           Size:       2007 MB
S lvmr1.p1.s0           State: up       D: d2           Size:       2007 MB
root(at)nudel tmp> vinum start lvmr5.p0.s3
root(at)nudel tmp> vinum ls
S lvmr5.p0.s0           State: up       D: d3           Size:       1004 MB
S lvmr5.p0.s1           State: up       D: d4           Size:       1004 MB
S lvmr5.p0.s2           State: up       D: d5           Size:       1004 MB
S lvmr5.p0.s3           State: up       D: d6           Size:       1004 MB
S lvmr1.p0.s0           State: up       D: d1           Size:       2007 MB
S lvmr1.p1.s0           State: up       D: d2           Size:       2007 MB
root(at)nudel tmp> 
Hm.. nun brauchte ich gar nix machen... das RAID-5 funktioniert
wieder. Sehr komisch.
  Gruesse, Oliver
-- 
 Oliver Lehmann
  http://www.pofo.de/
  http://wishlist.ans-netz.de/
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message

Received on Fri 30 Jan 2004 - 23:19:37 CET