Date: Sat, 30 Mar 1996 18:54:03 +0100 (MET) From: grog@lemis.de (Greg Lehey) To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-scsi@FreeBSD.ORG, nirva@mail.zynet.com, holm@geophysik.tu-freiberg.de, current@allegro.lemis.de Subject: Re: More Nakamichi problems Message-ID: <199603301754.SAA10980@allegro.lemis.de> In-Reply-To: <199603290901.KAA29758@uriah.heep.sax.de> from "J Wunsch" at Mar 29, 96 10:01:27 am
next in thread | previous in thread | raw e-mail | index | archive | help
J Wunsch writes:
>
> As Danny Dulai wrote:
>
>> I think I have a defective Nakamichi MBR-7 CD changer, but I
>> want to confirm if I'm the only one having this problem.
>>
>> I can't seem to read ANY CDs that are CD-Rs... every other
>> CD works, the CD-Rs just freeze up, the cd changer keeps
>> reading reading. It doesn't work under FreeBSD, but it does
>> in DOS.
>>
>> Anyone else having similar problems?
>
> Holm, can you say anything about this? (You should really subscribe
> to this list, anyway.)
Well, I now have a Nakamichi as well, and I don't have *that*
particular problem. I find it quite easy to panic the machine with
concurrent access to the machine (as simple as trying to mount all the
disks sequentially; something in the background wants to go and check
the other disks). They symptoms are a bus hang for several seconds,
followed by a panic:
panic: vref used where vget required
During symbol reading, debug info mismatch between compiler and debugger.
#0 boot (howto=256) at ../../i386/i386/machdep.c:942
942 dumppcb.pcb_ptd = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../i386/i386/machdep.c:942
#1 0xf0119ac7 in panic (fmt=0xf0131f2e "vref used where vget required") at ../../kern/subr_prf.c:133
#2 0xf0131f62 in vref (vp=0xf0cead80) at ../../kern/vfs_subr.c:815
#3 0xf010476d in iso_iget (xp=0xefbffdc4, ino=73728, relocated=1, ipp=0xefbffd50, isodir=0xf0d60344)
at ../../isofs/cd9660/cd9660_node.c:238
#4 0xf01066e9 in cd9660_root (mp=0xf0d60600, vpp=0xefbffe70) at ../../isofs/cd9660/cd9660_vfsops.c:497
#5 0xf0130bec in lookup (ndp=0xefbfff00) at ../../kern/vfs_lookup.c:475
#6 0xf01305c0 in namei (ndp=0xefbfff00) at ../../kern/vfs_lookup.c:149
#7 0xf013340d in statfs (p=0xf0d68700, uap=0xefbfff94, retval=0xefbfff84) at ../../kern/vfs_syscalls.c:418
#8 0xf01bb46d in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 53504, tf_esi = -272640788, tf_ebp = -272640956,
tf_isp = -272629788, tf_ebx = -272640908, tf_edx = 10, tf_ecx = 61, tf_eax = 157, tf_trapno = 0, tf_err = 7,
tf_eip = 12333, tf_cs = 31, tf_eflags = 642, tf_esp = -272641240, tf_ss = 39}) at ../../i386/i386/trap.c:904
#9 0xf01b2f95 in Xsyscall ()
#10 0x1866 in ?? ()
#11 0x165d in ?? ()
#12 0x14ee in ?? ()
#13 0x1066 in ?? ()
Looking down the stack, the vnode is either bogus or overwritten:
(kgdb) f2
#2 0xf0131f62 in vref (vp=0xf0cead80) at ../../kern/vfs_subr.c:815
815 panic("vref used where vget required");
esp: 0xefbffcac (9 words on stack)
ebp: 0xefbffce0
eip: 0xf0131f62 <vref+22>: nop
Saved ebp: 0xefbffd1c (maximum of 11 parameters possible)
Saved eip: 0xf010476d <iso_iget+325>: addl $0x8,%esp
Parm 1 at 0xefbffce8: 0xf0cead80 ""
Parm 2 at 0xefbffcec: 0xf0d4f800 "Ü~\037ðÜ~\037ð"
Parm 3 at 0xefbffcf0: 0xf0d60200 ""
Parm 4 at 0xefbffcf4: 0xf0d60344 "D"
(kgdb) f 2
#2 0xf0131f62 in vref (vp=0xf0cead80) at ../../kern/vfs_subr.c:815
815 panic("vref used where vget required");
(kgdb) l
810 vref(vp)
811 struct vnode *vp;
812 {
813
814 if (vp->v_usecount <= 0)
815 panic("vref used where vget required");
816 vp->v_usecount++;
817 }
818
819 /*
(kgdb) p *vp
$1 = {
v_flag = 74581447,
v_usecount = 305397760,
v_writecount = 1793427797,
v_holdcnt = -661873406,
v_lastr = -393289586,
v_id = 294275,
v_mount = 0x7d833874,
v_op = 0x1740018,
v_freelist = {
tqe_next = 0x1c5d8bf4,
tqe_prev = 0xf883038b
},
v_mntvnodes = {
le_next = 0xb8077401,
le_prev = 0x1
},
v_cleanblkhd = {
lh_first = 0x738bc3c9
},
v_dirtyblkhd = {
lh_first = 0xfe8304
},
v_numoutput = 12130420,
v_type = -1929379836,
v_un = {
vu_mountedhere = 0x1e30203d,
vu_socket = 0x1e30203d,
vu_specinfo = 0x1e30203d,
vu_fifoinfo = 0x1e30203d
},
v_lease = 0x2f3e8000,
v_lastw = 130418036,
v_cstart = -62306513,
v_lasta = 213492979,
v_clen = -150994944,
v_ralen = 2117,
v_usage = 57966592,
v_maxra = -1993323637,
v_object = 0x1024bfde,
v_tag = -108855266,
v_data = 0xb9057648
}
(kgdb) x/10 0x1c5d8bf4
0x1c5d8bf4: Cannot access memory at address 0x1c5d8bf4.
I'm currently tossing up between analyzing the dump further and using
this as a test case for testing my ddb extensions (conditional memory
access breakpoints); don't expect me to do either for a while.
Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603301754.SAA10980>