Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 Nov 2002 22:08:56 -0700
From:      "Kenneth D. Merry" <ken@kdm.org>
To:        David Kleiner <kleiner@panix.com>
Cc:        Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp>, Dmitry Mottl <dima@sinp.msu.ru>, freebsd-firewire@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG
Subject:   Re: VAIO Firewire dock station with DVD-ROM
Message-ID:  <20021105220856.A48288@panzer.kdm.org>
In-Reply-To: <20021105090033.GA29210@panix.com>; from kleiner@panix.com on Tue, Nov 05, 2002 at 04:00:33AM -0500
References:  <ybs4rbasjfn.wl@ett.sat.t.u-tokyo.ac.jp> <20021025184837.C227-100000@localhost> <ybs1y6esb8n.wl@ett.sat.t.u-tokyo.ac.jp> <20021104073302.GA27648@panix.com> <ybs1y60loxq.wl@ett.sat.t.u-tokyo.ac.jp> <20021104210348.A41448@panzer.kdm.org> <20021105060143.GA24764@panix.com> <20021104231825.A42046@panzer.kdm.org> <20021105090033.GA29210@panix.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 05, 2002 at 04:00:33 -0500, David Kleiner wrote:
> On Mon, Nov 04, 2002 at 11:18:25PM -0700, Kenneth D. Merry wrote:
> > On Tue, Nov 05, 2002 at 01:01:43 -0500, David Kleiner wrote:
> > > On Mon, Nov 04, 2002 at 09:03:48PM -0700, Kenneth D. Merry wrote:
> > > > On Tue, Nov 05, 2002 at 11:40:01 +0900, Hidetoshi Shimokawa wrote:
> > > > > At Mon, 4 Nov 2002 02:33:02 -0500,
> > > > > David Kleiner wrote:
> > > > > > 
> > > > > > Hidetoshi-san,
> > > > > > 
> > > > > > I have just rebuilt my RELENG_4 world with just imported 
> > > > > > firewire support. 
> > > > > > 
> > > > > > Here is what I am getting when trying to run cdcontrol:
> > > > > ..
> > > > > > (cd0:sbp0:0:0:0): MODE SENSE(06). CDB: 1a 0 e 0 1c 0 
> > > > > > (cd0:sbp0:0:0:0): ILLEGAL REQUEST asc:20,0
> > > > > > (cd0:sbp0:0:0:0): Invalid command operation code
> > > > > 
> > > > > Could you try the CAM patch which Ken posted to the list?
> > > > 
> > > > I've attached a -stable version of the patch.
> > > > 
> > > > Keep in mind that this version has a bit of extra debugging output, so
> > > > don't be alarmed if it is a bit more chatty than you expect.
> > > > 
> > > > Ken
> > > > -- 
> > > > Kenneth Merry
> > > > ken@kdm.org
> > > 
> > > Ken,
> > > 
> > > I had applied your patch and rebuilt kernel - when I tried
> > > cdcontrol/cdplay, I got this streaming messages below (very 
> > > chatty).  CD didn't play, system eventually crashed, unfortunately,
> > > I don't have the dump.
> > 
> > It looks like that's the result of a brain-o.  I forgot to change the
> > opcode.
> > 
> > I've attached a new patch.  It still has extra debugging output, in case
> > something doesn't work right.
> > 
> > Ken
> > -- 
> > Kenneth Merry
> > ken@kdm.org
> 
> Ken,
> 
> Still doesn't :(  I re-applied the patch, errors are not streaming to
> /var/log/messages! 
> 
> What I get when trying to do 
> 
> cdcontrol> status :
> 
> Nov  5 00:05:37 mal /kernel: sbp0:0:0 SCSI status 2 sfmt 0 valid 0 key 2 code 4
> qlfr 1 len 7
> Nov  5 00:05:38 mal /kernel: sbp0:0:0 ORB status src:1 resp:0 dead:0 len:7 stat:
> c orb:0000244d8
> Nov  5 00:05:38 mal /kernel: sbp0:0:0 Request aborted
> Nov  5 00:05:38 mal /kernel: sbp0:0:0 XPT_SCSI_IO: cmd: 00 00 00 00 00 00 00 00 
> 00 00, flags: 0xc0, 6b cmd/0b data/32b sense
> Nov  5 00:05:38 mal /kernel: sbp0:0:0 SCSI status 2 sfmt 0 valid 0 key 2 code 4
> qlfr 1 len 7
> Nov  5 00:05:38 mal /kernel: sbp0:0:0 ORB status src:1 resp:0 dead:0 len:7 stat:
> c orb:00002460c
> Nov  5 00:05:38 mal /kernel: sbp0:0:0 Request aborted
> Nov  5 00:05:38 mal /kernel: sbp0:0:0 XPT_SCSI_IO: cmd: 00 00 00 00 00 00 00 00 
> 00 00, flags: 0xc0, 6b cmd/0b data/32b sense
> Nov  5 00:05:38 mal /kernel: sbp0:0:0 SCSI status 2 sfmt 0 valid 0 key 2 code 4
> qlfr 1 len 7
> Nov  5 00:05:39 mal /kernel: sbp0:0:0 ORB status src:1 resp:0 dead:0 len:7 stat:
> c orb:000024740
> Nov  5 00:05:39 mal /kernel: sbp0:0:0 Request aborted

If the mode sense/mode select handling code triggered, you should be seeing
the "MODE_SENSE(6)/MODE_SELECT(6) failed, increasing minimum CDB size to 10
bytes" printf...

> At some point, the system crashed:
> 
> panicstr: from debugger
> panic messages:

So you broke into the debugger and paniced the system?  That panic message
is what happens when you type 'panic' from the ddb prompt.

> ---
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0x14
> fault code              = supervisor read, page not present
> instruction pointer     = 0x8:0xc0274ef6
> stack pointer           = 0x10:0xd3c4bd40
> frame pointer           = 0x10:0xd3c4bd70
> 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         = 202 (xconsole)
> interrupt mask          = tty 
> sbp0:0:0 ORB status src:1 resp:0 dead:0 len:7 stat:c orb:0000243a4
> sbp0:0:0 Request aborted
> sbp0:0:0 XPT_SCSI_IO: cmd: 1a 00 0e 00 1c 00 00 00 18 00, flags: 0x40, 6b cmd/32b data/32b sense
> sbp0:0:0 SCSI status 2 sfmt 0 valid 0 key 5 code 20 qlfr 0 len 7
> 
> 
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0x14
> fault code              = supervisor read, page not present
> instruction pointer     = 0x8:0xc0274ef6
> stack pointer           = 0x10:0xd3c4bd40
> frame pointer           = 0x10:0xd3c4bd70
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> interrupt mask          = tty 
> panic: from debugger
> 
> 
> Fatal trap 3: breakpoint instruction fault while in kernel mode
> instruction pointer     = 0x8:0xc0268df1

Breakpoint instruction?  Did you set a breakpoint?

> stack pointer           = 0x10:0xd3c4bb54
> frame pointer           = 0x10:0xd3c4bb5c
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = interrupt enabled, IOPL = 0
> current process         = 202 (xconsole)
> interrupt mask          = tty 
> panic: from debugger
> Uptime: 18m40s
> 
> dumping to dev #ad/0x30001, offset 659712
> 
> I have the dump (didn't write this out by heart :) - please let me know
> if I can give more information.

Well, if the system really is panicing somewhere, it would be good to get a
stack trace.

If you hook up a serial console, you can get it from ddb.  You can also get
a stack trace from the crash dump if you do something like:

gdb -k kernel.debug vmcore.0
where

Ken
-- 
Kenneth Merry
ken@kdm.org

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021105220856.A48288>