Re: busdma/scsi trm(4) related panic

2003-08-14 Thread Scott Long
Ruslan Ermilov wrote:
On Wed, Aug 06, 2003 at 07:42:06AM -0600, Scott Long wrote:

I know what the problem is and I'm working on a patch right now.

I have the same problem with amd(4) and this commit to busdma_machdep.c.

Cheers,
Attached is an untested patch for amd(4).  Please let me know if it
fixes your problem.
Scott
Index: amd.c
===
RCS file: /home/ncvs/src/sys/dev/amd/amd.c,v
retrieving revision 1.22
diff -u -r1.22 amd.c
--- amd.c   31 Jul 2003 16:55:44 -  1.22
+++ amd.c   9 Aug 2003 06:44:28 -
@@ -2115,12 +2115,26 @@
 {
u_int16_t  count, i;
struct amd_srb *psrb;
+   int error;
 
count = amd-SRBCount;
 
for (i = 0; i  count; i++) {
psrb = (struct amd_srb *)amd-SRB_array[i];
psrb-TagNumber = i;
+
+   /*
+* Create the dmamap.  This is no longer optional!
+*
+* XXX Since there is no detach method in this driver,
+* this does not get freed!
+*/
+   if ((error = bus_dmamap_create(amd-buffer_dmat, 0,
+  psrb-dmamap)) != 0) {
+   device_printf(amd-dev, Error %d creating buffer 
+ dmamap!\n, error);
+   return;
+   }
TAILQ_INSERT_TAIL(amd-free_srbs, psrb, links);
}
 }
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: busdma/scsi trm(4) related panic

2003-08-14 Thread Scott Long
I know what the problem is and I'm working on a patch right now.

Scott

Jon Kuster wrote:
On Wed, 2003-08-06 at 05:00, Craig Rodrigues wrote:

On Tue, Aug 05, 2003 at 11:08:33PM -0700, Jon Kuster wrote:

If there's anything you'd like me to type at the db prompt, just ask
and I'll send the output.
Send the backtrace, with the 't' command.


Here you go.  Once again, this was hand transcribed, so sorry for any
typos.
-Jon
db t
_bus_dmamap_load_buffer(c3fd3c40,c044660,c4193e84,24,0) at
_bus_dmamap_load_buffer+0x3ff
bus_dmamap_load(c3fd3c40,0,c4193e84,24,c01c9760) at bus_dmamap_load+0x6c
trm_action(c406c200,c418dc00,c0130cc4,c4193e00,c4193e00) at
trm_action+0x27a
xpt_run_dev_sendq(c406c1c0,c4193e18,1,7,4) at xpt_run_dev_sendq+0x192
xpt_release_devq_device(c4193e00,1,1,d68fbcec,c0243b5e) at
xpt_release_devq_device+0xe2
xpt_release_devq_timeout(c4193e00,c1521974,10,f8c6020d,c0131dd0) at
xpt_release_devq_timeout+0x21
softclock (0,0,0,0,c1521974) at softclock+0x24e
ithread_loop(c1520280,d68fbd48,0,0,c1520280) at ithread_loop+0x1c8
fork_exit(c021d770,c1520280,d68fbd48 at fork_exit+0xb1
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xd68fbd7c, ebp = 0 ---
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


busdma/scsi trm(4) related panic

2003-08-14 Thread Jon Kuster
Hi,

I've been getting what appears to be a busdma / scsi related panic for
the past couple of days.  This is based solely on what little info I get
when it drops to the debugger - I haven't been able to get a core dump. 
It panics during the boot process immediately after it tries to probe my
scsi devices (just a cdrom) attached to my Tekram DC-315U adapter.  If I
remove trm(4) from my kernel, I can boot without a panic, but if I load
the trm module, and then issue `camcontrol rescan all` it will panic. 
Reverting /usr/src/sys/i386/i386/busdma_machdep.c to version 1.52 lets
me boot and use my scsi devices without panics. Version 1.53 will panic
too.

This is with -current sources as of 5:57am MST (12:47UTC) on Aug. 5.  
FreeBSD jonnyv.kwsn.lan 5.1-CURRENT FreeBSD 5.1-CURRENT #3: Tue Aug  5
21:09:50 MST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/JONNYV  i386


Here's what little info I have (apologies for typos, I had to transcribe
this by hand):

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x0
fault code  = supervisor write, page not present
instruction pointer = 0x8:0xc35682f
stack pointer   = 0x10:0xd68fbb94
frame pointer   = 0x10:0xd68fbbd8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 12 (swi7: tty:sio clock)
kernel: type 12 trap, code = 0
Stopped at _bus_dmamap_load_buffer+0x3ff: movl %ecx,0(%edx,%eax,8)

$ nm -n /boot/kernel/kernel | grep c03568
c03568e0 T bus_dmamap_load

If there's anything you'd like me to type at the db prompt, just ask
and I'll send the output.

Thanks,
Jon

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: busdma/scsi trm(4) related panic

2003-08-14 Thread Jon Kuster
On Wed, 2003-08-06 at 06:42, Scott Long wrote:
 I know what the problem is and I'm working on a patch right now.
 
 Scott

Excellent.  I'll be happy to test it if needed.

Jon

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: busdma/scsi trm(4) related panic

2003-08-14 Thread Jon Kuster
On Wed, 2003-08-06 at 05:00, Craig Rodrigues wrote:
 On Tue, Aug 05, 2003 at 11:08:33PM -0700, Jon Kuster wrote:
  If there's anything you'd like me to type at the db prompt, just ask
  and I'll send the output.
 
 Send the backtrace, with the 't' command.

Here you go.  Once again, this was hand transcribed, so sorry for any
typos.
-Jon

db t
_bus_dmamap_load_buffer(c3fd3c40,c044660,c4193e84,24,0) at
_bus_dmamap_load_buffer+0x3ff
bus_dmamap_load(c3fd3c40,0,c4193e84,24,c01c9760) at bus_dmamap_load+0x6c
trm_action(c406c200,c418dc00,c0130cc4,c4193e00,c4193e00) at
trm_action+0x27a
xpt_run_dev_sendq(c406c1c0,c4193e18,1,7,4) at xpt_run_dev_sendq+0x192
xpt_release_devq_device(c4193e00,1,1,d68fbcec,c0243b5e) at
xpt_release_devq_device+0xe2
xpt_release_devq_timeout(c4193e00,c1521974,10,f8c6020d,c0131dd0) at
xpt_release_devq_timeout+0x21
softclock (0,0,0,0,c1521974) at softclock+0x24e
ithread_loop(c1520280,d68fbd48,0,0,c1520280) at ithread_loop+0x1c8
fork_exit(c021d770,c1520280,d68fbd48 at fork_exit+0xb1
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xd68fbd7c, ebp = 0 ---

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: busdma/scsi trm(4) related panic

2003-08-14 Thread Jon Kuster
On Fri, 2003-08-08 at 23:46, Scott Long wrote:
 Attached is an untested patch.  Please let me know if it solves the
 problem
 
 Scott

That did the trick.  Thanks!

Jon

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: busdma/scsi trm(4) related panic

2003-08-09 Thread Scott Long
Jon Kuster wrote:
On Wed, 2003-08-06 at 06:42, Scott Long wrote:

I know what the problem is and I'm working on a patch right now.

Scott


Excellent.  I'll be happy to test it if needed.

Jon


Attached is an untested patch.  Please let me know if it solves the
problem
Scott
Index: trm.c
===
RCS file: /home/ncvs/src/sys/dev/trm/trm.c,v
retrieving revision 1.12
diff -u -r1.12 trm.c
--- trm.c   1 Jul 2003 15:52:02 -   1.12
+++ trm.c   9 Aug 2003 06:45:05 -
@@ -2999,6 +2999,7 @@
 {
u_int16_ti;
PSRBpSRB;
+   int error;
 
for (i = 0; i  TRM_MAX_SRB_CNT; i++) {
pSRB = (PSRB)pACB-pFreeSRB[i];
@@ -3040,6 +3041,17 @@
pSRB-pNextSRB = NULL;
}
pSRB-TagNumber = i;
+
+   /*
+* Create the dmamap.  This is no longer optional!
+*
+* XXX This is not freed on unload!  None of the other
+* allocations in this function are either!
+*/
+   if ((error = bus_dmamap_create(pACB-buffer_dmat, 0,
+  pSRB-dmamap)) != 0)
+   return (error);
+
}
return (0);
 }
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]