Doug Rabson | 1 Jan 11:16 2004

Re: IRQ 2 problem

On Wed, 2003-12-31 at 20:25, M. Warner Losh wrote:
> In message: <XFMail.20031231141216.jhb <at> FreeBSD.org>
>             John Baldwin <jhb <at> FreeBSD.org> writes:
> : 
> : On 31-Dec-2003 Rostislav Krasny wrote:
> : > --- "M. Warner Losh" <imp <at> bsdimp.com> wrote:
> : >> In message: <20031230.190927.108191769.imp <at> bsdimp.com>
> : >>             "M. Warner Losh" <imp <at> bsdimp.com> writes:
> : >> : The reason that it iasn't been committed is because it is
> : >> incorrect.
> : >> : 
> : >> :
> : >>
> : > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=15473+0+archive/2003/freebsd-arch/20030831.freebsd-ar
> : > ch
> : >> : 
> : >> : has the particulars.
> : >> 
> : >> Does your machine have an APIC?  My laptop doesn't seem to exhibit
> : >> the problem.
> : > 
> : > No, it doesn't seem to have an APIC. This is Pentium MMX 200MHz machine
> : > based on Intel's 430TX chipset.
> : > 
> : > What is the correct way to fix this IRQ 2 problem? I can help to test it.
> : 
> : IRQ 2 in FreeBSD is spelled IRQ 9.  If a PNP device wants to use IRQ 2, it
> : can be set to IRQ 2 in hardware, but it must use IRQ 9 when doing the
> : bus_alloc_resource() and bus_setup_intr().
> 
(Continue reading)

M. Warner Losh | 1 Jan 11:34 2004

Re: IRQ 2 problem

In message: <1072952198.3233.24.camel <at> herring.nlsystems.com>
            Doug Rabson <dfr <at> nlsystems.com> writes:
: On Wed, 2003-12-31 at 20:25, M. Warner Losh wrote:
: > In message: <XFMail.20031231141216.jhb <at> FreeBSD.org>
: >             John Baldwin <jhb <at> FreeBSD.org> writes:
: > : 
: > : On 31-Dec-2003 Rostislav Krasny wrote:
: > : > --- "M. Warner Losh" <imp <at> bsdimp.com> wrote:
: > : >> In message: <20031230.190927.108191769.imp <at> bsdimp.com>
: > : >>             "M. Warner Losh" <imp <at> bsdimp.com> writes:
: > : >> : The reason that it iasn't been committed is because it is
: > : >> incorrect.
: > : >> : 
: > : >> :
: > : >>
: > : > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=15473+0+archive/2003/freebsd-arch/20030831.freebsd-ar
: > : > ch
: > : >> : 
: > : >> : has the particulars.
: > : >> 
: > : >> Does your machine have an APIC?  My laptop doesn't seem to exhibit
: > : >> the problem.
: > : > 
: > : > No, it doesn't seem to have an APIC. This is Pentium MMX 200MHz machine
: > : > based on Intel's 430TX chipset.
: > : > 
: > : > What is the correct way to fix this IRQ 2 problem? I can help to test it.
: > : 
: > : IRQ 2 in FreeBSD is spelled IRQ 9.  If a PNP device wants to use IRQ 2, it
: > : can be set to IRQ 2 in hardware, but it must use IRQ 9 when doing the
(Continue reading)

David Xu | 1 Jan 16:24 2004
Picon

Re: sigaltstack with threads

Doug Rabson wrote:
> I think that if its supported at all in threaded programs, it must be
> per-thread state otherwise you can't prevent two different threads
> colliding on the same signal stack. I can't quite see how this maps to
> KSE/KSEG since I only have the most hazy model of that stuff in my head
> right now.
> 
> Anyway, I've worked around things by not setting SA_ONSTACK for the
> handlers that I want to run on the thread stack.
> 
> 
I have worked out a patch to support per-thread sigaltstack() state,
in most cases, it is just a literally replacement.

http://people.freebsd.org/~davidxu/kse/kern_sigaltstack.diffs

David Xu

_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"

Doug Rabson | 1 Jan 16:56 2004

Re: sigaltstack with threads

On Thu, 2004-01-01 at 15:24, David Xu wrote:
> Doug Rabson wrote:
> > I think that if its supported at all in threaded programs, it must be
> > per-thread state otherwise you can't prevent two different threads
> > colliding on the same signal stack. I can't quite see how this maps to
> > KSE/KSEG since I only have the most hazy model of that stuff in my head
> > right now.
> > 
> > Anyway, I've worked around things by not setting SA_ONSTACK for the
> > handlers that I want to run on the thread stack.
> > 
> > 
> I have worked out a patch to support per-thread sigaltstack() state,
> in most cases, it is just a literally replacement.
> 
> http://people.freebsd.org/~davidxu/kse/kern_sigaltstack.diffs

Looks fine to me.

_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"

Daniel Eischen | 1 Jan 17:48 2004

Re: sigaltstack with threads

On Thu, 1 Jan 2004, David Xu wrote:

> Doug Rabson wrote:
> > I think that if its supported at all in threaded programs, it must be
> > per-thread state otherwise you can't prevent two different threads
> > colliding on the same signal stack. I can't quite see how this maps to
> > KSE/KSEG since I only have the most hazy model of that stuff in my head
> > right now.
> > 
> > Anyway, I've worked around things by not setting SA_ONSTACK for the
> > handlers that I want to run on the thread stack.
> > 
> > 
> I have worked out a patch to support per-thread sigaltstack() state,
> in most cases, it is just a literally replacement.
> 
> http://people.freebsd.org/~davidxu/kse/kern_sigaltstack.diffs

Looks good, but I have a question.  You removed the proc lock
in kern_sig.c:osigstack() and kern_sig.c:kern_sigaltstack().
What prevents a signal from being sent to the current thread
while it is mucking with the altsigstack?  Is it possible for
an interrupt to swap out the current thread and have a signal
installed for it sometime later before it can complete
sigaltstack()?  Or do signals only get installed on the way
out of the kernel?

--

-- 
Dan Eischen

(Continue reading)

David Xu | 2 Jan 01:26 2004
Picon

Re: sigaltstack with threads

Daniel Eischen wrote:
> On Thu, 1 Jan 2004, David Xu wrote:
> 
> 
>>Doug Rabson wrote:
>>
>>>I think that if its supported at all in threaded programs, it must be
>>>per-thread state otherwise you can't prevent two different threads
>>>colliding on the same signal stack. I can't quite see how this maps to
>>>KSE/KSEG since I only have the most hazy model of that stuff in my head
>>>right now.
>>>
>>>Anyway, I've worked around things by not setting SA_ONSTACK for the
>>>handlers that I want to run on the thread stack.
>>>
>>>
>>
>>I have worked out a patch to support per-thread sigaltstack() state,
>>in most cases, it is just a literally replacement.
>>
>>http://people.freebsd.org/~davidxu/kse/kern_sigaltstack.diffs
> 
> 
> Looks good, but I have a question.  You removed the proc lock
> in kern_sig.c:osigstack() and kern_sig.c:kern_sigaltstack().
> What prevents a signal from being sent to the current thread
> while it is mucking with the altsigstack?  Is it possible for
> an interrupt to swap out the current thread and have a signal
> installed for it sometime later before it can complete
> sigaltstack()?  Or do signals only get installed on the way
(Continue reading)

John Baldwin | 2 Jan 17:31 2004
Picon

Re: IRQ 2 problem


On 01-Jan-2004 M. Warner Losh wrote:
> In message: <1072952198.3233.24.camel <at> herring.nlsystems.com>
>             Doug Rabson <dfr <at> nlsystems.com> writes:
>: On Wed, 2003-12-31 at 20:25, M. Warner Losh wrote:
>: > In message: <XFMail.20031231141216.jhb <at> FreeBSD.org>
>: >             John Baldwin <jhb <at> FreeBSD.org> writes:
>: > : 
>: > : On 31-Dec-2003 Rostislav Krasny wrote:
>: > : > --- "M. Warner Losh" <imp <at> bsdimp.com> wrote:
>: > : >> In message: <20031230.190927.108191769.imp <at> bsdimp.com>
>: > : >>             "M. Warner Losh" <imp <at> bsdimp.com> writes:
>: > : >> : The reason that it iasn't been committed is because it is
>: > : >> incorrect.
>: > : >> : 
>: > : >> :
>: > : >>
>: > : > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=15473+0+archive/2003/freebsd-arch/20030831.fre
>: > : > ebsd-ar
>: > : > ch
>: > : >> : 
>: > : >> : has the particulars.
>: > : >> 
>: > : >> Does your machine have an APIC?  My laptop doesn't seem to exhibit
>: > : >> the problem.
>: > : > 
>: > : > No, it doesn't seem to have an APIC. This is Pentium MMX 200MHz machine
>: > : > based on Intel's 430TX chipset.
>: > : > 
>: > : > What is the correct way to fix this IRQ 2 problem? I can help to test it.
(Continue reading)

M. Warner Losh | 2 Jan 17:37 2004

Re: IRQ 2 problem

In message: <XFMail.20040102113123.jhb <at> FreeBSD.org>
            John Baldwin <jhb <at> FreeBSD.org> writes:
: > It looks like IRQ2 isn't registered as an interrupt source, so when we
: > create the resource map, it looks like we skip it and shouldn't be
: > handing it out...
: 
: Yes, it doesn't exist as a valid IRQ in the irq map anymore.  Oh, but you
: know what, the resource manager is really buggy in this respect.  For example,
: on my system here:
: 
: Interrupt request lines:
:     0x0 (root0)
:     0x1 (atkbd0)
:     0x2 (root0)
:     0x3 (sio1)
:     0x4 (sio0)
:     0x5-0x8 (root0)
:     0x9 (acpi0)
:     0xa-0xb (root0)
:     0xc (psm0)
:     0xd (npx0)
:     0xe (ata0)
:     0xf (ata1)
:     0x10 (uhci0)
:     0x11 (sis0)
:     0x12 (uhci2)
:     0x13 (uhci1)
:     0x14 (fxp0)
:     0x15-0x17 (root0)
: 
(Continue reading)

John Baldwin | 2 Jan 19:27 2004
Picon

Re: IRQ 2 problem


On 02-Jan-2004 M. Warner Losh wrote:
> In message: <XFMail.20040102113123.jhb <at> FreeBSD.org>
>             John Baldwin <jhb <at> FreeBSD.org> writes:
>: > It looks like IRQ2 isn't registered as an interrupt source, so when we
>: > create the resource map, it looks like we skip it and shouldn't be
>: > handing it out...
>: 
>: Yes, it doesn't exist as a valid IRQ in the irq map anymore.  Oh, but you
>: know what, the resource manager is really buggy in this respect.  For example,
>: on my system here:
>: 
>: Interrupt request lines:
>:     0x0 (root0)
>:     0x1 (atkbd0)
>:     0x2 (root0)
>:     0x3 (sio1)
>:     0x4 (sio0)
>:     0x5-0x8 (root0)
>:     0x9 (acpi0)
>:     0xa-0xb (root0)
>:     0xc (psm0)
>:     0xd (npx0)
>:     0xe (ata0)
>:     0xf (ata1)
>:     0x10 (uhci0)
>:     0x11 (sis0)
>:     0x12 (uhci2)
>:     0x13 (uhci1)
>:     0x14 (fxp0)
(Continue reading)

M. Warner Losh | 2 Jan 19:31 2004

Re: IRQ 2 problem

In message: <XFMail.20040102132720.jhb <at> FreeBSD.org>
            John Baldwin <jhb <at> FreeBSD.org> writes:
: On 02-Jan-2004 M. Warner Losh wrote:
: > In message: <XFMail.20040102113123.jhb <at> FreeBSD.org>
: >             John Baldwin <jhb <at> FreeBSD.org> writes:
: >: > It looks like IRQ2 isn't registered as an interrupt source, so when we
: >: > create the resource map, it looks like we skip it and shouldn't be
: >: > handing it out...
: >: 
: >: Yes, it doesn't exist as a valid IRQ in the irq map anymore.  Oh, but you
: >: know what, the resource manager is really buggy in this respect.  For example,
: >: on my system here:
: >: 
: >: Interrupt request lines:
: >:     0x0 (root0)
: >:     0x1 (atkbd0)
: >:     0x2 (root0)
: >:     0x3 (sio1)
: >:     0x4 (sio0)
: >:     0x5-0x8 (root0)
: >:     0x9 (acpi0)
: >:     0xa-0xb (root0)
: >:     0xc (psm0)
: >:     0xd (npx0)
: >:     0xe (ata0)
: >:     0xf (ata1)
: >:     0x10 (uhci0)
: >:     0x11 (sis0)
: >:     0x12 (uhci2)
: >:     0x13 (uhci1)
(Continue reading)


Gmane