Date: Thu, 14 Jan 1999 22:00:01 -0800 (PST) From: "Kenneth D. Merry" <ken@plutotech.com> To: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/9482: cdrecord fails under -current (12/Jan/99) (panic) Message-ID: <199901150600.WAA18304@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/9482; it has been noted by GNATS. From: "Kenneth D. Merry" <ken@plutotech.com> To: doconnor@lot.gsoft.com.au Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: kern/9482: cdrecord fails under -current (12/Jan/99) (panic) Date: Thu, 14 Jan 1999 22:56:00 -0700 (MST) Daniel O'Connor wrote... > > >Number: 9482 > >Category: kern > >Synopsis: cdrecord fails under -current (12/Jan/99) (panic) > >Confidential: no > >Severity: serious > >Priority: high > >Responsible: freebsd-bugs > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Wed Jan 13 19:40:01 PST 1999 > >Closed-Date: > >Last-Modified: > >Originator: Daniel O'Connor > >Release: FreeBSD 2.2.7-STABLE i386 > >Organization: > Genesis Software > >Environment: > A 3.0-current made on the 12th of January. > cdrecord compiled under 2.2.7+CAM and a recompiled version for 3.0 > > This is a Supermicro P6SBS (BX) which has a 7895 SCSI controller on the mobo. > The CDR is a Matsushita CW-7502 which works fine on a 2.2.7r+-CAM system. > > >Description: > The 2.2.7+CAM causes the machine to hang and then panic. > The CDR is ID 6, and when I run cdrecord -scanbus I get this from the kernel -> > (This happens when it gets to the 6th device, the CDR) > > (pass0:ahc0:0:6:0): SCB 0x6 - timed out in command phase, SCSISIGI == 0x96 > SEQADDR == 0x7d > SSTAT1 == 0x3 > (pass0:ahc0:0:6:0): no longer in timeout, status = 34b > ahc0: Issued Channel A Bus Reset. 1 SCBs aborted > panic: ahc0: brkadrint, (null) at seqaddr = 0x0 > > (this has happened twice, last time seqaddr was 0x1) That can happen for a number of reasons. Sometimes a drive will just go out to lunch if it doesn't like the command it received. It could also be a cabling/termination problem. > The recompiled version of cdrecord gets the following (immediate panic) -> Which version of cdrecord are you using? > --- > #0 0xf014c947 in boot () > (kgdb) where > #0 0xf014c947 in boot () > #1 0xf014cbe5 in panic () > #2 0xf012aef1 in db_panic () > #3 0xf012ae91 in db_command () > #4 0xf012af56 in db_command_loop () > #5 0xf012d2a7 in db_trap () > #6 0xf01f50fe in kdb_trap () > #7 0xf01ff31c in trap_fatal () > #8 0xf01feffb in trap_pfault () > #9 0xf01fec4a in trap () > #10 0xf011ae54 in xpt_path_comp () > #11 0xf0119990 in xpt_action () > #12 0xf0118220 in xptioctl () Do you have the debugging code turned on? And did you, by any chance, have tracing (CAM_DEBUG_TRACE) turned on at the time? I don't see many other ways we could have gotten from xpt_action() to xpt_path_comp(), unless you're missing some stack frames in there. > >How-To-Repeat: > run cdrecord -scanbus on a 3.0 machine with a CDR attached Try using the version of cdrecord in the ports tree (1.6.1). You can also try cdrecord 1.8a15, but you'll need to patch it to use a smaller read/write size. (DFLTPHYS - PAGE_SIZE instead of MAXPHYS) Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901150600.WAA18304>