Your stack traceback looks like lis_strrput was waking up ioctl, which means doing an "up" on the semaphore. I don't see why it would get stuck unless the semaphore had indeed been destroyed. But you fix closes the hole in that logic.
You might try putting a piece of code something like this in lis_up_fcn()
if (!strcmp(lsem->owner_file,"De-Initialized"))
printk("lis_down(%p) De-Initialized semaphore %s #%d\n", lsem, file, line) ;
-- Dave
At 07:09 PM 5/13/2004, Eugene LiS User wrote:
Hi,
I have a problem where lis_strrput() tries to do lis_wake_up_wiocing(hd)
which ends up looping on the spinlock attached to
that sd_wiocing semaphore.
#0 [edbb1cec] crash_save_current_state at c0116920
#1 [edbb1cf0] do_nmi at c01084bf
#2 [edbb1d10] nmi at c0107a0d
EAX: eb9a7cb4 EBX: eb9a7390 ECX: 00000001 EDX: 00000003 EBP: edbb1d6c
DS: 0018 ESI: f8ab1430 ES: 0018 EDI: eb9a7cb4
CS: 0010 EIP: c0119905 ERR: eb9a7cb4 EFLAGS: 00000086
#3 [edbb1d4c] _text_lock_sched (via __wake_up) at c0119905
#4 [edbb1d70] __up at c01061c3
#5 [edbb1d78] __up_wakeup at c01063fb
#6 [edbb1d88] _text_lock_KBUILD_BASENAME (via lis_up_fcn) at f8a4bf43
#7 [edbb1d8c] lis_strrput at f8a35b1d
bt: text symbols on stack:
[edbb1cf0] do_nmi at c01084c4
[edbb1d10] nmi at c0107a12
[edbb1d44] _text_lock_sched at c0119905
[edbb1d50] lis_spin_unlock_irqrestore_fcn at f8a4b9f5
[edbb1d70] __up at c01061c8
[edbb1d78] __up_wakeup at c0106400
[edbb1d88] _text_lock_KBUILD_BASENAME at f8a4bf48
[edbb1d8c] lis_strrput at f8a35b22
[edbb1db4] lis_safe_putmsg at f8a47bbe
[edbb1dd4] mydrv_ursrv at f8a69ff1
[edbb1df4] queuerun at f8a4838c
[edbb1e3c] LisUpCounter at f8a47d8b
[edbb1e60] allocdb at f8a3d645
[edbb1e7c] lis_allocb at f8a3d7be
[edbb1ea0] copyin_msgpart at f8a3378d
[edbb1ed0] lis_run_queues at f8a48595
[edbb1ee8] lis_setqsched at f8a446c9
[edbb1f10] lis_strputpmsg at f8a38fbb
[edbb1f30] lis_strwrite at f8a383b0
[edbb1f94] sys_write at c013fb7c
[edbb1fc0] system_call at c0107897
[edbb1fe0] startup_32 at c010002b
bt: possible exception frames:
A couple of suspicious thing that I have noticed with regard
to that sd_wiocing semaphore:
1.
In lis_strdoioctl()
SEM_DESTROY(&hd->sd_wiocing) is called before CLR_SD_FLAG(hd,IOCWAIT),
that IOCWAIT flag is used for some sort of synchronization,
so I think that SEM_DESTROY(&hd->sd_wiocing) should be called
_after_ CLR_SD_FLAG(hd,IOCWAIT).
2.
In lis_do_tmout()
The lis_wake_up_wiocing(hd) is called without
checking if (F_ISSET(hd->sd_flag,IOCWAIT)).
For consistency sake I would expect it to be
if (F_ISSET(hd->sd_flag,IOCWAIT))
lis_wake_up_wiocing(hd);
I fixed both places. It did not help at all.
Any suggestion on how to debug this further?
--
Eugene
__________________________________________________________________
Introducing the New Netscape Internet Service.
Only $9.95 a month -- Sign up today at http://isp.netscape.com/register
Netscape. Just the Net You Need.
New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp
_______________________________________________
Linux-streams mailing list
[EMAIL PROTECTED]
http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.663 / Virus Database: 426 - Release Date: 4/20/2004
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.663 / Virus Database: 426 - Release Date: 4/20/2004
