From doconnor@lot.gsoft.com.au  Wed Jan 13 19:32:26 1999
Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA08564
          for <FreeBSD-gnats-submit@freebsd.org>; Wed, 13 Jan 1999 19:32:24 -0800 (PST)
          (envelope-from doconnor@lot.gsoft.com.au)
Received: from lot.gsoft.com.au (doconnor@lot.gsoft.com.au [203.38.152.106])
	by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id OAA23634
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 14 Jan 1999 14:01:14 +1030 (CST)
	(envelope-from doconnor@lot.gsoft.com.au)
Received: (from doconnor@localhost)
	by lot.gsoft.com.au (8.8.8/8.8.8) id OAA08095;
	Thu, 14 Jan 1999 14:02:24 +1030 (CST)
	(envelope-from doconnor)
Message-Id: <199901140332.OAA08095@lot.gsoft.com.au>
Date: Thu, 14 Jan 1999 14:02:24 +1030 (CST)
From: "Daniel O'Connor" <doconnor@lot.gsoft.com.au>
Reply-To: doconnor@lot.gsoft.com.au
To: FreeBSD-gnats-submit@freebsd.org
Subject: cdrecord fails under -current (12/Jan/99) (panic)
X-Send-Pr-Version: 3.2

>Number:         9482
>Category:       kern
>Synopsis:       cdrecord fails under -current (12/Jan/99) (panic)
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    ken
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jan 13 19:40:01 PST 1999
>Closed-Date:    Mon Jan 18 17:22:47 PST 1999
>Last-Modified:  Mon Jan 18 17:23:38 PST 1999
>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)

The recompiled version of cdrecord gets the following (immediate panic) ->
(gdb -k from the crash dump)
IdlePTD 2846720
initial pcb at 24fe50
panicstr: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x4
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xf011ae54
stack pointer           = 0x10:0xf4583b64
frame pointer           = 0x10:0xf4583b68
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 373 (cdrecord)
interrupt mask          = 
panic: from debugger
panic: from debugger

dumping to dev 20001, offset 278528
dump 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 
38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12
 11 10 9 8 7 6 5 4 3 2 1 
---
#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 ()
#13 0xf0179c6f in spec_ioctl ()
#14 0xf0179581 in spec_vnoperate ()
#15 0xf01d8519 in ufs_vnoperatespec ()
#16 0xf0174469 in vn_ioctl ()
#17 0xf015694c in ioctl ()
#18 0xf01ff59f in syscall ()
#19 0xf01f5a4c in Xint0x80_syscall ()
#20 0x8051351 in ?? ()
#21 0x80491f2 in ?? ()
#22 0x8048fe1 in ?? ()

>How-To-Repeat:
run cdrecord -scanbus on a 3.0 machine with a CDR attached

>Fix:
	

>Release-Note:
>Audit-Trail:

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
State-Changed-From-To: open->feedback 
State-Changed-By: ken 
State-Changed-When: Thu Jan 14 22:01:41 PST 1999 
State-Changed-Why:  
I sent the PR author some mail, and asked him some questions about his 
configuration, versions, etc... 


Responsible-Changed-From-To: freebsd-bugs->ken 
Responsible-Changed-By: ken 
Responsible-Changed-When: Thu Jan 14 22:01:41 PST 1999 
Responsible-Changed-Why:  
I wrote or am responsible for most of the software in question. 

From: "Daniel O'Connor" <doconnor@gsoft.com.au>
To: "Kenneth D. Merry" <ken@plutotech.com>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, doconnor@lot.gsoft.com.au
Subject: Re: kern/9482: cdrecord fails under -current (12/Jan/99) (panic)
Date: Fri, 15 Jan 1999 16:43:38 +1030 (CST)

 On 15-Jan-99 Kenneth D. Merry wrote:
 > > The recompiled version of cdrecord gets the following (immediate panic) ->
 >  Which version of cdrecord are you using?
 The old version was 1.6, the recompiled version was 1.6.1
 The reason I recompiled was because the old version was compiled under 2.2+CAM.
 
 >  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 had debugging on (info, trace, cdb)
 
 >  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.
 OK..
 I just recompiled the kernel without debugging, and it fixed the problem! 
 Hmm =)
 
 Thanks for the help.
 
 ---
 Daniel O'Connor software and network engineer
 for Genesis Software - http://www.gsoft.com.au
 "The nice thing about standards is that there
 are so many of them to choose from."
   -- Andrew Tanenbaum

From: "Kenneth D. Merry" <ken@plutotech.com>
To: doconnor@gsoft.com.au (Daniel O'Connor)
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/9482: cdrecord fails under -current (12/Jan/99) (panic)
Date: Thu, 14 Jan 1999 23:15:51 -0700 (MST)

 Daniel O'Connor wrote...
 > 
 > On 15-Jan-99 Kenneth D. Merry wrote:
 > > > The recompiled version of cdrecord gets the following (immediate panic) ->
 > >  Which version of cdrecord are you using?
 > The old version was 1.6, the recompiled version was 1.6.1
 > The reason I recompiled was because the old version was compiled under 2.2+CAM.
 > 
 > >  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 had debugging on (info, trace, cdb)
 
 Ahh, well that explains it.
 
 > >  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.
 > OK..
 > I just recompiled the kernel without debugging, and it fixed the problem! 
 > Hmm =)
 
 Well, you certainly found a bug.  The bug is that the CCB passed in from
 xptioctl() for XPT_DEV_MATCH requests didn't have a valid path.  It doesn't
 need to have a valid path for the matching code, but it does for the
 debugging code.
 
 All you really need to disable is the 'trace' debugging.  The CDB debugging
 is really the most useful kind, and should still work fine.
 
 Ken
 -- 
 Kenneth Merry
 ken@plutotech.com

From: "Daniel O'Connor" <doconnor@gsoft.com.au>
To: "Kenneth D. Merry" <ken@plutotech.com>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/9482: cdrecord fails under -current (12/Jan/99) (panic)
Date: Fri, 15 Jan 1999 16:49:40 +1030 (CST)

 On 15-Jan-99 Kenneth D. Merry wrote:
 >  All you really need to disable is the 'trace' debugging.  The CDB debugging
 >  is really the most useful kind, and should still work fine.
 Yeah, OK.. I was just fiddling with the knobs to see what they do :)
 
 ---
 Daniel O'Connor software and network engineer
 for Genesis Software - http://www.gsoft.com.au
 "The nice thing about standards is that there
 are so many of them to choose from."
   -- Andrew Tanenbaum
State-Changed-From-To: feedback->closed 
State-Changed-By: ken 
State-Changed-When: Mon Jan 18 17:22:47 PST 1999 
State-Changed-Why:  
I fixed this in revision 1.38 of cam_xpt.c.  If that revision doesn't fix 
the problem for you, please let me know. 
>Unformatted:
