Re: [Asterisk-bsd] NMI ISA 30, EISA ff
I haven't any ideas yet. Have same on i7325 chipset on 5.4 stable.
Best regards,
Konstantin Prokazoff
Center Of Excellence, S_V_R Ltd., Kyiv HQs, Ukraine
Official business-partner & DevConnect member of Avaya Inc.
Regional development & support center of Digium Inc.
Tel. +38 044 594 1781, ext. 1038
Fax. +38 044 234 0455
- Original Message -
From: "Mark Ackroyd" <[EMAIL PROTECTED]>
To: "'Asterisk on BSD discussion'"
Sent: Thursday, December 15, 2005 2:52 PM
Subject: [Asterisk-bsd] NMI ISA 30, EISA ff
> Hiya all,
>
> just installed the latest version of the BSD zaptel drivers (from svn) on
a
> bran new FreeBSD 6 machine. As soon as Zaptel loads my /var/log/messages
> file gets filed with
>
> Dec 15 07:53:04 hathor kernel: NMI ISA 20, EISA ff
> Dec 15 07:53:04 hathor kernel: NMI ISA 30, EISA ff
> Dec 15 07:53:04 hathor kernel: NMI ISA 30, EISA ff
> Dec 15 07:53:04 hathor kernel: NMI ISA 20, EISA ff
> Dec 15 07:53:04 hathor last message repeated 4 times
> Dec 15 07:53:04 hathor kernel: NMI ISA 30, EISA ff
> Dec 15 07:53:04 hathor kernel: NMI ISA 30, EISA ff
> Dec 15 07:53:04 hathor kernel: NMI ISA 20, EISA ff
> Dec 15 07:53:04 hathor last message repeated 2 times
> Dec 15 07:53:04 hathor kernel: NMI ISA 30, EISA ff
>
> Someone left some debug code in the zaptel driver? what does this mean? ..
> at the moment it's just filling up disk space :-)
>
> Anyone got any ideas?
>
> Thanks,
> Mark
>
>
>
>
>
>
>
> ___
> Asterisk-BSD mailing list
> Asterisk-BSD@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-bsd
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.371 / Virus Database: 267.13.13/200 - Release Date:
14.12.2005
>
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: poll()/select()
Now, have checking non-FAST handler. Have some interest moments, such as error codes, like: Short write: 0/15 (Programming error) Write to 137 (fdno) failed: Programming error Maybe server becomes overloaded? (4xE1, Xeon 3G) Best regards, Konstantin Prokazoff Center Of Excellence, S_V_R Ltd., Kyiv HQs, Ukraine Official business-partner & DevConnect member of Avaya Inc. Regional development & support center of Digium Inc. Tel. +38 044 594 1781, ext. 1038 Fax. +38 044 234 0455 - Original Message - From: "John Baldwin" <[EMAIL PROTECTED]> To: Cc: "Konstantin Prokazoff" <[EMAIL PROTECTED]> Sent: Monday, November 21, 2005 5:38 PM Subject: Re: poll()/select() > On Monday 21 November 2005 08:14 am, Konstantin Prokazoff wrote: > > Thanks for comment, > > > > I think, after kernel inspection, problem (maybe) in preemption. While > > syscall to poll or select holds sellock, and if another thread (process) > > tries to syscall or we have taken interrupt (where handler use > > selrecord/selwakeup too), kernel will deadlock. > > I have this situation cause to INTR_FAST interrupt handler in device > > driver for Digium's PCI board, which provides 4 T1/E1 interfaces. Problem > > 100% repetitive. > > Another way to avoid such deadlock - provide different kthread/ithreads > > for select/poll mechanism. > > You can't call selwakeup() from an INTR_FAST handler. Try removing INTR_FAST > and see if it fixes your issue. If you want to use INTR_FAST, then realize > that you can only use spin mutexes in your handler, and that any more > complicated work like selwakeup() that uses regular mutexes will have to be > deferred either by using a swi handler or dispatching a task to the Fast > taskqueue. > > -- > John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: poll()/select()
Welcome, John, thanks for the answer. I'll test today bus_setup_intr() without INTR_FAST flag, but how I remember, this cause to system heavy load for interrupt processing ;( in my case. My handler uses spin mutexes to block inter-interrupting & sleep mutexes to block some structures now. I have tried to use swi/taskqueue, but result is a "sync" degradation level. Can you help with sources briefing in my driver case? Thnx in advance. Best regards, Konstantin Prokazoff Center Of Excellence, S_V_R Ltd., Kyiv HQs, Ukraine Official business-partner & DevConnect member of Avaya Inc. Regional development & support center of Digium Inc. Tel. +38 044 594 1781, ext. 1038 Fax. +38 044 234 0455 - Original Message - From: "John Baldwin" <[EMAIL PROTECTED]> To: Cc: "Konstantin Prokazoff" <[EMAIL PROTECTED]> Sent: Monday, November 21, 2005 5:38 PM Subject: Re: poll()/select() > On Monday 21 November 2005 08:14 am, Konstantin Prokazoff wrote: > > Thanks for comment, > > > > I think, after kernel inspection, problem (maybe) in preemption. While > > syscall to poll or select holds sellock, and if another thread (process) > > tries to syscall or we have taken interrupt (where handler use > > selrecord/selwakeup too), kernel will deadlock. > > I have this situation cause to INTR_FAST interrupt handler in device > > driver for Digium's PCI board, which provides 4 T1/E1 interfaces. Problem > > 100% repetitive. > > Another way to avoid such deadlock - provide different kthread/ithreads > > for select/poll mechanism. > > You can't call selwakeup() from an INTR_FAST handler. Try removing INTR_FAST > and see if it fixes your issue. If you want to use INTR_FAST, then realize > that you can only use spin mutexes in your handler, and that any more > complicated work like selwakeup() that uses regular mutexes will have to be > deferred either by using a swi handler or dispatching a task to the Fast > taskqueue. > > -- > John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: poll()/select()
Thanks for comment,
I think, after kernel inspection, problem (maybe) in preemption. While
syscall to poll or select holds sellock, and if another thread (process)
tries to syscall or we have taken interrupt (where handler use
selrecord/selwakeup too), kernel will deadlock.
I have this situation cause to INTR_FAST interrupt handler in device
driver for Digium's PCI board, which provides 4 T1/E1 interfaces. Problem
100% repetitive.
Another way to avoid such deadlock - provide different kthread/ithreads
for select/poll mechanism.
Best regards,
Konstantin Prokazoff
Center Of Excellence, S_V_R Ltd., Kyiv HQs, Ukraine
Official business-partner & DevConnect member of Avaya Inc.
Regional development & support center of Digium Inc.
Tel. +38 044 244 1181, ext. 1038
Fax. +38 044 234 0455
- Original Message -
From: <[EMAIL PROTECTED]>
To: "Konstantin Prokazoff" <[EMAIL PROTECTED]>;
Sent: Monday, November 21, 2005 2:42 PM
Subject: Re: poll()/select()
> At 10:29 AM 11/21/2005 +0200, Konstantin Prokazoff wrote:
> | Welcome everybody,
> |
> | have a strange issue under 5.x/6.x (checked).
> | When using a poll()/select() mechanism, which in kernel based on
> | selrecord/selwakeup (pollscan, kern_select) functions, we have deadlock
on
> | sellock mutex on heavy load (recursive lock on non-recursive mutex).
Have
> | anyone seen this? Deadlock can be reached only if kernel w'be compiled
with
> | debugger, because in different case system locks, your can't login, etc.
> | Maybe one path to resolve - change behavour of sched_lock & sellock
mutexes
> | block/unblock order.
> | Thnx in advance & for comments.
> |
> | Best regards,
> | Konstantin Prokazoff
> | Center Of Excellence, S_V_R Ltd., Kyiv HQs, Ukraine
> | Official business-partner & DevConnect member of Avaya Inc.
> | Regional development & support center of Digium Inc.
> | Tel. +38 044 244 1181, ext. 1038
> | Fax. +38 044 234 0455
>
> The only thing I can add is that a sys admin friend of mine did try using
the
> poll/select to increase performance and had to finally abandon it due to
> instability problems under load.
>
> I've never tried it first hand myself. Not sure if that helps you.
>
> Ray
>
>
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
poll()/select()
Welcome everybody,
have a strange issue under 5.x/6.x (checked).
When using a poll()/select() mechanism, which in kernel based on
selrecord/selwakeup (pollscan, kern_select) functions, we have deadlock on
sellock mutex on heavy load (recursive lock on non-recursive mutex). Have
anyone seen this? Deadlock can be reached only if kernel w'be compiled with
debugger, because in different case system locks, your can't login, etc.
Maybe one path to resolve - change behavour of sched_lock & sellock mutexes
block/unblock order.
Thnx in advance & for comments.
Best regards,
Konstantin Prokazoff
Center Of Excellence, S_V_R Ltd., Kyiv HQs, Ukraine
Official business-partner & DevConnect member of Avaya Inc.
Regional development & support center of Digium Inc.
Tel. +38 044 244 1181, ext. 1038
Fax. +38 044 234 0455
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
