From owner-freebsd-scsi Sat Mar 30 10:16:15 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA22951 for freebsd-scsi-outgoing; Sat, 30 Mar 1996 10:16:15 -0800 (PST) Received: from diablo.ppp.de (diablo.ppp.de [193.141.101.34]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA22937 for ; Sat, 30 Mar 1996 10:16:08 -0800 (PST) Received: from allegro.lemis.de by diablo.ppp.de with smtp (Smail3.1.28.1 #1) id m0u35Bz-000QYDC; Sat, 30 Mar 96 19:16 MET From: grog@lemis.de (Greg Lehey) Organisation: LEMIS, Schellnhausen 2, 36325 Feldatal, Germany Phone: +49-6637-919123 Fax: +49-6637-919122 Received: (grog@localhost) by allegro.lemis.de (8.6.9/8.6.9) id SAA10980; Sat, 30 Mar 1996 18:54:04 +0100 Message-Id: <199603301754.SAA10980@allegro.lemis.de> Subject: Re: More Nakamichi problems To: joerg_wunsch@uriah.heep.sax.de Date: Sat, 30 Mar 1996 18:54:03 +0100 (MET) Cc: freebsd-scsi@FreeBSD.ORG, nirva@mail.zynet.com, holm@geophysik.tu-freiberg.de, current@allegro.lemis.de In-Reply-To: <199603290901.KAA29758@uriah.heep.sax.de> from "J Wunsch" at Mar 29, 96 10:01:27 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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 : nop Saved ebp: 0xefbffd1c (maximum of 11 parameters possible) Saved eip: 0xf010476d : 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