Re: the PS/2 mouse problem
Bruce Evans wrote: On Sat, 8 Nov 2003, Morten Johansen wrote: Scott Long wrote: Bruce Evans wrote: [... possibly too much trimmed] The problem here is that the keyboard controller driver tries to be too smart. If it detects that the hardware FIFO is full, it'll drain it into a per-softc, per-function ring buffer. So having psm(4) just directly read the hardware is insufficient in this scheme. What is the per-function part? (I'm not very familar with psm, but once understood simpler versions of the keyboard driver.) Several layers of buffering might not be too bad for slow devices. The i/o times tend to dominate unless you do silly things like a context switch to move each character from one buffer to other, and even that can be fast enough (I believe it is normal for interactive input on ptys; then there's often a remote IPC or two per character as well). The atkbdc (keyboard controller, not keyboard) contains two 'kqueue' objects, one for the keyboard device and one for the 'aux' device. This 'kqueue' is a linked list of buffers for holding characters when the driver detects that the hardware FIFO is full. Unfortunately, it checks all over the place, and tends to check both the 'kbd' and 'aux' ports at the same time (the 'aux' port is for psm, presumably). So, this complicates the locking of psm quite a bit since it calls read_aux_data_no_wait() which looks at the aux kqueue and also services the keyboard queue at the same time. My gut feeling is that by making the kbd and psm drivers be INTR_FAST (or INTR_DIRECT as it should be called), there is little chance that the hardware fifo will overflow before the isr can run. The driver interrupt handlers can then have their own private queues with some simple locking or atomic lists that get serviced by a taskqueue. However, I'm not sure if my assumption is correct on very old hardware like 486/586 and old Alphas. Also, I'm unclear on whether you need to read the status register before reading the data register. Hanging out for 7us in the isr in order to do the back-to-back reads doesn't thrill me. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: the PS/2 mouse problem
Scott Long wrote:
Bruce Evans wrote:
On Sat, 8 Nov 2003, Morten Johansen wrote:
Scott Long wrote:
Bruce Evans wrote:
[... possibly too much trimmed]
The problem here is that the keyboard controller driver tries to be too
smart. If it detects that the hardware FIFO is full, it'll drain it
into
a per-softc, per-function ring buffer. So having psm(4) just directly
read the hardware is insufficient in this scheme.
What is the per-function part? (I'm not very familar with psm, but once
understood simpler versions of the keyboard driver.) Several layers of
buffering might not be too bad for slow devices. The i/o times tend to
dominate unless you do silly things like a context switch to move each
character from one buffer to other, and even that can be fast enough
(I believe it is normal for interactive input on ptys; then there's often
a remote IPC or two per character as well).
The atkbdc (keyboard controller, not keyboard) contains two 'kqueue'
objects, one for the keyboard device and one for the 'aux' device.
This 'kqueue' is a linked list of buffers for holding characters when
the driver detects that the hardware FIFO is full. Unfortunately, it
checks all over the place, and tends to check both the 'kbd' and 'aux'
ports at the same time (the 'aux' port is for psm, presumably). So,
this complicates the locking of psm quite a bit since it calls
read_aux_data_no_wait() which looks at the aux kqueue and also services
the keyboard queue at the same time.
My gut feeling is that by making the kbd and psm drivers be INTR_FAST
(or INTR_DIRECT as it should be called), there is little chance that the
hardware fifo will overflow before the isr can run. The driver
interrupt handlers can then have their own private queues with some
simple locking or atomic lists that get serviced by a taskqueue.
However, I'm not sure if my assumption is correct on very old hardware
like 486/586 and old Alphas. Also, I'm unclear on whether you need
to read the status register before reading the data register. Hanging
out for 7us in the isr in order to do the back-to-back reads doesn't
thrill me.
Scott
FWIW, this is what the Linux (2.6) driver does:
static inline int i8042_read_data(void)
{
return inb(I8042_DATA_REG);
}
static inline int i8042_read_status(void)
{
return inb(I8042_STATUS_REG);
}
... and in the isr:
while (j I8042_BUFFER_SIZE
(buffer[j].str = i8042_read_status()) I8042_STR_OBF)
buffer[j++].data = i8042_read_data();
... this isr then figures out if it's kbd or aux data (based on status
register) and calls the appropriate sub-isr (i.e. ps/2) with the data.
There are noe delays as far as I can see.
Why did we need the delays? Can they be removed?
Morten
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: the PS/2 mouse problem
On Sat, 8 Nov 2003, Morten Johansen wrote:
Scott Long wrote:
Bruce Evans wrote:
[... possibly too much trimmed]
The problem here is that the keyboard controller driver tries to be too
smart. If it detects that the hardware FIFO is full, it'll drain it into
a per-softc, per-function ring buffer. So having psm(4) just directly
read the hardware is insufficient in this scheme.
What is the per-function part? (I'm not very familar with psm, but once
understood simpler versions of the keyboard driver.) Several layers of
buffering might not be too bad for slow devices. The i/o times tend to
dominate unless you do silly things like a context switch to move each
character from one buffer to other, and even that can be fast enough
(I believe it is normal for interactive input on ptys; then there's often
a remote IPC or two per character as well).
- it sometimes calls the DELAY() function, which is not permitted in fast
interrupt handlers since apart from locking issues, fast interrupt
handlers
are not permitted to busy-wait.
Again, the keyboard controller driver is too smart for its own good. To
summarize:
read_aux_data_no_wait()
{
Does softc-aux ring buffer contain data?
return ring buffer data
Check the status register
Is the keyboard fifo full?
DELAY(7us)
read keyboard fifo into softc-kbd ring buffer
Check the status register
Is the aux fifo full?
DELAY(7us)
return aux fifo data
}
So you can wind up stalling for 14us in there, presumably because you
cannot read the status and data registers back-to-back without a delay.
I don't have the atkbd spec handy so I'm not sure how to optimize this.
Do you really need to check the status register before reading the data
register?
At least it's a bounded delay. I believe such delays are required for
some layers of the keyboard. Perhaps only for the keyboard (old hardware
only?) and not for the keyboard controller or the mouse.
Many of the complications for fast interrupt handlers shouldn't be needed
in psm. Just make psmintr() INTR_MPSAFE.
I believe that the previous poster actually tried making it INTR_MPSAFE,
but didn't see a measurable benefit because the latency of scheduling
the ithread is still unacceptable.
That is 100% correct.
In the meantime I have taken your's and Bruce's advice and rearranged
the interrupt handler to look like this:
mtx_lock(sc-input_mtx);
Er, this is reasonable for INTR_MPSAFE but not for INTR_FAST.
mtx_lock() is a sleep lock so it cannot be used in fast interrupt
handlers. mtx_lock_spin() must be used. (My version doesn't permit
use of mtx_lock_spin() either; more primitive locking must be used.)
while((c = read_aux_data_no_wait(sc-kbdc)) != -1) {
This is probably INTR_FAST-safe enough in practice.
sc-input_queue.buf[sc-input_queue.tail] = c;
if ((++ sc-input_queue.tail) = PSM_BUFSIZE)
sc-input_queue.tail = 0;
count = (++ sc-input_queue.count);
}
mtx_unlock(sc-input_mtx);
The locking for the queue seems to be correct except this should operate
on a spinlock too.
if (count = sc-mode.packetsize)
taskqueue_enqueue(taskqueue_swi_giant, sc-psm_task);
taskqueue_enqueue() can only be used in non-fast interrupt handlers.
taskqueue_enqueue_fast() must be used in fast interrupt handlers (except
in my version, it is not permitted so it shouldn't exist). Note that
the spinlock/fast versions can be used for normal interrupt handlers
too, so not much more code is needed to support handlers whose fastness
is dynamically configured.
And it works, but having it INTR_MPSAFE still does NOT help my problem.
It looks to me like data is getting lost because the interrupt handler
is unable to read it before it's gone, and the driver gets out of sync,
and has to reset itself.
However it now takes a few more tries to provoke the problem, so
something seems to have improved somewhere.
This is a bit surprising. There are still so few INTR_MPSAFE handlers
that there aren't many system activities that get in the way of running
the INTR_MPSAFE ones. Shared interrupts prevent running of a handler
while other handlers on the same interrupt are running, and the mouse
interrupt is often shared, but if it is shared then it couldn't be fast
until recently and still can't be fast unless all the other handlers on
it are fast.
Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: the PS/2 mouse problem
Bruce Evans wrote:
On Sat, 8 Nov 2003, Morten Johansen wrote:
Scott Long wrote:
Bruce Evans wrote:
[... possibly too much trimmed]
The problem here is that the keyboard controller driver tries to be too
smart. If it detects that the hardware FIFO is full, it'll drain it into
a per-softc, per-function ring buffer. So having psm(4) just directly
read the hardware is insufficient in this scheme.
What is the per-function part? (I'm not very familar with psm, but once
understood simpler versions of the keyboard driver.) Several layers of
buffering might not be too bad for slow devices. The i/o times tend to
dominate unless you do silly things like a context switch to move each
character from one buffer to other, and even that can be fast enough
(I believe it is normal for interactive input on ptys; then there's often
a remote IPC or two per character as well).
- it sometimes calls the DELAY() function, which is not permitted in fast
interrupt handlers since apart from locking issues, fast interrupt
handlers
are not permitted to busy-wait.
Again, the keyboard controller driver is too smart for its own good. To
summarize:
read_aux_data_no_wait()
{
Does softc-aux ring buffer contain data?
return ring buffer data
Check the status register
Is the keyboard fifo full?
DELAY(7us)
read keyboard fifo into softc-kbd ring buffer
Check the status register
Is the aux fifo full?
DELAY(7us)
return aux fifo data
}
So you can wind up stalling for 14us in there, presumably because you
cannot read the status and data registers back-to-back without a delay.
I don't have the atkbd spec handy so I'm not sure how to optimize this.
Do you really need to check the status register before reading the data
register?
At least it's a bounded delay. I believe such delays are required for
some layers of the keyboard. Perhaps only for the keyboard (old hardware
only?) and not for the keyboard controller or the mouse.
Many of the complications for fast interrupt handlers shouldn't be needed
in psm. Just make psmintr() INTR_MPSAFE.
I believe that the previous poster actually tried making it INTR_MPSAFE,
but didn't see a measurable benefit because the latency of scheduling
the ithread is still unacceptable.
That is 100% correct.
In the meantime I have taken your's and Bruce's advice and rearranged
the interrupt handler to look like this:
mtx_lock(sc-input_mtx);
Er, this is reasonable for INTR_MPSAFE but not for INTR_FAST.
mtx_lock() is a sleep lock so it cannot be used in fast interrupt
handlers. mtx_lock_spin() must be used. (My version doesn't permit
use of mtx_lock_spin() either; more primitive locking must be used.)
while((c = read_aux_data_no_wait(sc-kbdc)) != -1) {
This is probably INTR_FAST-safe enough in practice.
sc-input_queue.buf[sc-input_queue.tail] = c;
if ((++ sc-input_queue.tail) = PSM_BUFSIZE)
sc-input_queue.tail = 0;
count = (++ sc-input_queue.count);
}
mtx_unlock(sc-input_mtx);
The locking for the queue seems to be correct except this should operate
on a spinlock too.
if (count = sc-mode.packetsize)
taskqueue_enqueue(taskqueue_swi_giant, sc-psm_task);
taskqueue_enqueue() can only be used in non-fast interrupt handlers.
taskqueue_enqueue_fast() must be used in fast interrupt handlers (except
in my version, it is not permitted so it shouldn't exist). Note that
the spinlock/fast versions can be used for normal interrupt handlers
too, so not much more code is needed to support handlers whose fastness
is dynamically configured.
Yes, I have submitted a PR (kern/59067), with an INTR_FAST version that
uses spinlocks and taskqueue_fast.
You can find it here if you have time to look at it:
http://dsm.oslonett.no/patch-psm-fast
I would appreciate comments on it's correctness.
And it works, but having it INTR_MPSAFE still does NOT help my problem.
It looks to me like data is getting lost because the interrupt handler
is unable to read it before it's gone, and the driver gets out of sync,
and has to reset itself.
However it now takes a few more tries to provoke the problem, so
something seems to have improved somewhere.
This is a bit surprising. There are still so few INTR_MPSAFE handlers
that there aren't many system activities that get in the way of running
the INTR_MPSAFE ones. Shared interrupts prevent running of a handler
while other handlers on the same interrupt are running, and the mouse
interrupt is often shared, but if it is shared then it couldn't be fast
until recently and still can't be fast unless all the other handlers on
it are fast.
Bruce
It seems odd that it should be necessary to have it INTR_FAST.
But somehow it is, on my system.
Morten
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: the PS/2 mouse problem
On Wed, Nov 05, 2003 at 08:33:58PM -0700, Scott Long wrote: One thought that I had was to make psmintr() be INTR_FAST. I need to stare at the code some more to fully understand it, but it looks like it wouldn't be all that hard to do. Basically just use the interrupt handler to pull all of the data out of the hardware and into a ring buffer in memory, and then a fast taskqueue to process that ring buffer. It would at least answer the question of whether the observed problems are due to ithread latency. And if done right, no locks would be needed in psmintr(). I seemed to have solved my mouse problem: [http://www.mail-archive.com/[EMAIL PROTECTED]/msg62824.html]. Solution: I disabled IPCA in the BIOS and the mouse problem went away. Does IPCA have anything to do with ACPI. Yes, I have googled and looked at anandtech forums and had no luck. In disabling IPCA have I disabled ACPI ? - aW ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: the PS/2 mouse problem
Bruce Evans wrote:
On Fri, 7 Nov 2003, Morten Johansen wrote:
Morten Johansen wrote:
Scott Long wrote:
One thought that I had was to make psmintr() be INTR_FAST. I need to
stare at the code some more to fully understand it, but it looks like it
wouldn't be all that hard to do. Basically just use the interrupt
handler
to pull all of the data out of the hardware and into a ring buffer in
memory, and then a fast taskqueue to process that ring buffer. It would
at least answer the question of whether the observed problems are due to
ithread latency. And if done right, no locks would be needed in
psmintr().
However, it is usually easier to use a lock even if not strictly necessary.
psm as currently structured uses the technique of calling psmintr() from
the timeout handler. This requires a lock. If this were not done, then
the timeout routine would probably need to access hardware using scattered
i/o instructions, and these would need locks (to prevent them competing
with i/o instructions in psmintr()). Putting all the hardware accesses
in the fast interrupt handler is simpler. The sio driver uses this technique
but doesn't manage to put _all_ the i/o's in the interrupt handler, so it
ends up having to lock out the interrupt handler all over the place.
Ring buffers can be self-locking using delicate atomic instructions, but
they are easier to implement using locks.
I can reproduce the problem consistently on my machine, by moving the
mouse around, while executing e.g this command in a xterm:
dd if=/dev/zero of=test bs=32768 count=4000; sync; sync; sync
when the sync'ing sets in the mouse attacks.
It is very likely due to interrupt latency.
I'd be happy to test any clever patches.
Wow. You are completly right!
By using a MTX_SPIN mutex instead, and marking the interrupt handler
INTR_MPSAFE | INTR_FAST, my problem goes away.
I am no longer able to reproduce the mouse attack.
I have not noticed any side-effects of this. Could there be any?
I will file a PR with an updated patch, unless you think it's a better
idea to rearrange the driver.
Probably the locking could be done better anyway.
Er, psmintr() needs large changes to become a fast interrupt handler. it
does many things that may not be done by a fast interrupt handler, starting
with the first statement in it:
/* read until there is nothing to read */
while((c = read_aux_data_no_wait(sc-kbdc)) != -1) {
This calls into the keyboard driver, which is not written to support any
fast interrupt handlers.
Actually, it calls the keyboard controller driver, not the keyboard
driver.
In general, fast interrupt handlers may not call
any functions, since the any function doesn't know that it is called in
fast interrupt handler context and may do things that may not be done in
fast interrupt handler context. As it happens, read_aux_data_no_wait()
does the following bad things:
- it accesses private keyboard data. All data that is accessed by a fast
interrupt handler must be locked by a common lock or use self-locking
accesses. Data in another subsystem can't reasonably be locked by this
(although the keyboard subsystem is close to psm, you don't want to
export the complexities of psmintr()'s locking to the keyboard subsystem).
- it calls other functions. The closure of all these calls must be examined
and made fast-interrupt-handler safe before this is safe. The lowest level
will resolve to something like inb(PSMPORT) and this alone is obviously
safe provided PSMPORT is only accessed in the interrupt handler or is
otherwise locked. (Perhaps the private keyboard data is actually private
psm data that mainly points to PSMPORT. Then there is no problem with the
data accesses. But the function calls make it unclear who owns the data.)
The problem here is that the keyboard controller driver tries to be too
smart. If it detects that the hardware FIFO is full, it'll drain it into
a per-softc, per-function ring buffer. So having psm(4) just directly
read the hardware is insufficient in this scheme.
- it sometimes calls the DELAY() function, which is not permitted in fast
interrupt handlers since apart from locking issues, fast interrupt handlers
are not permitted to busy-wait.
Again, the keyboard controller driver is too smart for its own good. To
summarize:
read_aux_data_no_wait()
{
Does softc-aux ring buffer contain data?
return ring buffer data
Check the status register
Is the keyboard fifo full?
DELAY(7us)
read keyboard fifo into softc-kbd ring buffer
Check the status register
Is the aux fifo full?
DELAY(7us)
return aux fifo data
}
So you can wind up stalling for 14us in there, presumably because you
cannot read the status and data registers back-to-back without a delay.
I don't have the atkbd spec handy so I'm not sure how to optimize this.
Do you really need to check the status register
Re: the PS/2 mouse problem
Scott Long wrote:
Bruce Evans wrote:
On Fri, 7 Nov 2003, Morten Johansen wrote:
Morten Johansen wrote:
Scott Long wrote:
One thought that I had was to make psmintr() be INTR_FAST. I need to
stare at the code some more to fully understand it, but it looks
like it
wouldn't be all that hard to do. Basically just use the interrupt
handler
to pull all of the data out of the hardware and into a ring buffer in
memory, and then a fast taskqueue to process that ring buffer. It
would
at least answer the question of whether the observed problems are
due to
ithread latency. And if done right, no locks would be needed in
psmintr().
However, it is usually easier to use a lock even if not strictly
necessary.
psm as currently structured uses the technique of calling psmintr() from
the timeout handler. This requires a lock. If this were not done, then
the timeout routine would probably need to access hardware using
scattered
i/o instructions, and these would need locks (to prevent them competing
with i/o instructions in psmintr()). Putting all the hardware accesses
in the fast interrupt handler is simpler. The sio driver uses this
technique
but doesn't manage to put _all_ the i/o's in the interrupt handler, so it
ends up having to lock out the interrupt handler all over the place.
Ring buffers can be self-locking using delicate atomic instructions, but
they are easier to implement using locks.
I can reproduce the problem consistently on my machine, by moving the
mouse around, while executing e.g this command in a xterm:
dd if=/dev/zero of=test bs=32768 count=4000; sync; sync; sync
when the sync'ing sets in the mouse attacks.
It is very likely due to interrupt latency.
I'd be happy to test any clever patches.
Wow. You are completly right!
By using a MTX_SPIN mutex instead, and marking the interrupt handler
INTR_MPSAFE | INTR_FAST, my problem goes away.
I am no longer able to reproduce the mouse attack.
I have not noticed any side-effects of this. Could there be any?
I will file a PR with an updated patch, unless you think it's a better
idea to rearrange the driver.
Probably the locking could be done better anyway.
Er, psmintr() needs large changes to become a fast interrupt handler. it
does many things that may not be done by a fast interrupt handler,
starting
with the first statement in it:
/* read until there is nothing to read */
while((c = read_aux_data_no_wait(sc-kbdc)) != -1) {
This calls into the keyboard driver, which is not written to support any
fast interrupt handlers.
Actually, it calls the keyboard controller driver, not the keyboard
driver.
In general, fast interrupt handlers may not call
any functions, since the any function doesn't know that it is called in
fast interrupt handler context and may do things that may not be done in
fast interrupt handler context. As it happens, read_aux_data_no_wait()
does the following bad things:
- it accesses private keyboard data. All data that is accessed by a fast
interrupt handler must be locked by a common lock or use self-locking
accesses. Data in another subsystem can't reasonably be locked by this
(although the keyboard subsystem is close to psm, you don't want to
export the complexities of psmintr()'s locking to the keyboard
subsystem).
- it calls other functions. The closure of all these calls must be
examined
and made fast-interrupt-handler safe before this is safe. The
lowest level
will resolve to something like inb(PSMPORT) and this alone is obviously
safe provided PSMPORT is only accessed in the interrupt handler or is
otherwise locked. (Perhaps the private keyboard data is actually
private
psm data that mainly points to PSMPORT. Then there is no problem
with the
data accesses. But the function calls make it unclear who owns the
data.)
The problem here is that the keyboard controller driver tries to be too
smart. If it detects that the hardware FIFO is full, it'll drain it into
a per-softc, per-function ring buffer. So having psm(4) just directly
read the hardware is insufficient in this scheme.
- it sometimes calls the DELAY() function, which is not permitted in fast
interrupt handlers since apart from locking issues, fast interrupt
handlers
are not permitted to busy-wait.
Again, the keyboard controller driver is too smart for its own good. To
summarize:
read_aux_data_no_wait()
{
Does softc-aux ring buffer contain data?
return ring buffer data
Check the status register
Is the keyboard fifo full?
DELAY(7us)
read keyboard fifo into softc-kbd ring buffer
Check the status register
Is the aux fifo full?
DELAY(7us)
return aux fifo data
}
So you can wind up stalling for 14us in there, presumably because you
cannot read the status and data registers back-to-back without a delay.
I don't have the atkbd spec handy so I'm not sure how to optimize this.
Do you really need to check the status register before reading the
Re: the PS/2 mouse problem
Morten Johansen wrote: Morten Johansen wrote: Scott Long wrote: One thought that I had was to make psmintr() be INTR_FAST. I need to stare at the code some more to fully understand it, but it looks like it wouldn't be all that hard to do. Basically just use the interrupt handler to pull all of the data out of the hardware and into a ring buffer in memory, and then a fast taskqueue to process that ring buffer. It would at least answer the question of whether the observed problems are due to ithread latency. And if done right, no locks would be needed in psmintr(). Scott I can reproduce the problem consistently on my machine, by moving the mouse around, while executing e.g this command in a xterm: dd if=/dev/zero of=test bs=32768 count=4000; sync; sync; sync when the sync'ing sets in the mouse attacks. It is very likely due to interrupt latency. I'd be happy to test any clever patches. Morten Wow. You are completly right! By using a MTX_SPIN mutex instead, and marking the interrupt handler INTR_MPSAFE | INTR_FAST, my problem goes away. I am no longer able to reproduce the mouse attack. I have not noticed any side-effects of this. Could there be any? I will file a PR with an updated patch, unless you think it's a better idea to rearrange the driver. Probably the locking could be done better anyway. Morten Great! By all means, please submit a PR and assign it to me. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: the PS/2 mouse problem
On Fri, 7 Nov 2003, Morten Johansen wrote:
Morten Johansen wrote:
Scott Long wrote:
One thought that I had was to make psmintr() be INTR_FAST. I need to
stare at the code some more to fully understand it, but it looks like it
wouldn't be all that hard to do. Basically just use the interrupt
handler
to pull all of the data out of the hardware and into a ring buffer in
memory, and then a fast taskqueue to process that ring buffer. It would
at least answer the question of whether the observed problems are due to
ithread latency. And if done right, no locks would be needed in
psmintr().
However, it is usually easier to use a lock even if not strictly necessary.
psm as currently structured uses the technique of calling psmintr() from
the timeout handler. This requires a lock. If this were not done, then
the timeout routine would probably need to access hardware using scattered
i/o instructions, and these would need locks (to prevent them competing
with i/o instructions in psmintr()). Putting all the hardware accesses
in the fast interrupt handler is simpler. The sio driver uses this technique
but doesn't manage to put _all_ the i/o's in the interrupt handler, so it
ends up having to lock out the interrupt handler all over the place.
Ring buffers can be self-locking using delicate atomic instructions, but
they are easier to implement using locks.
I can reproduce the problem consistently on my machine, by moving the
mouse around, while executing e.g this command in a xterm:
dd if=/dev/zero of=test bs=32768 count=4000; sync; sync; sync
when the sync'ing sets in the mouse attacks.
It is very likely due to interrupt latency.
I'd be happy to test any clever patches.
Wow. You are completly right!
By using a MTX_SPIN mutex instead, and marking the interrupt handler
INTR_MPSAFE | INTR_FAST, my problem goes away.
I am no longer able to reproduce the mouse attack.
I have not noticed any side-effects of this. Could there be any?
I will file a PR with an updated patch, unless you think it's a better
idea to rearrange the driver.
Probably the locking could be done better anyway.
Er, psmintr() needs large changes to become a fast interrupt handler. it
does many things that may not be done by a fast interrupt handler, starting
with the first statement in it:
/* read until there is nothing to read */
while((c = read_aux_data_no_wait(sc-kbdc)) != -1) {
This calls into the keyboard driver, which is not written to support any
fast interrupt handlers. In general, fast interrupt handlers may not call
any functions, since the any function doesn't know that it is called in
fast interrupt handler context and may do things that may not be done in
fast interrupt handler context. As it happens, read_aux_data_no_wait()
does the following bad things:
- it accesses private keyboard data. All data that is accessed by a fast
interrupt handler must be locked by a common lock or use self-locking
accesses. Data in another subsystem can't reasonably be locked by this
(although the keyboard subsystem is close to psm, you don't want to
export the complexities of psmintr()'s locking to the keyboard subsystem).
- it calls other functions. The closure of all these calls must be examined
and made fast-interrupt-handler safe before this is safe. The lowest level
will resolve to something like inb(PSMPORT) and this alone is obviously
safe provided PSMPORT is only accessed in the interrupt handler or is
otherwise locked. (Perhaps the private keyboard data is actually private
psm data that mainly points to PSMPORT. Then there is no problem with the
data accesses. But the function calls make it unclear who owns the data.)
- it sometimes calls the DELAY() function, which is not permitted in fast
interrupt handlers since apart from locking issues, fast interrupt handlers
are not permitted to busy-wait.
Many of the complications for fast interrupt handlers shouldn't be needed
in psm. Just make psmintr() INTR_MPSAFE. This is nontrival, however.
Fine grained locking gaves many of the complications that were only
in fast interrupt handlers in RELENG_4. E.g., for psmintr() to be MPSAFE,
all of its calls into the keyboard subsystem need to be MPSAFE, and they
are unlikely to be so unless the keyboard subsystem is made MPSAFE.
The following method can be used to avoid some of the complications:
make the interrupt handler not touch much data, so that it can be
locked easily. The data should be little more than a ring buffer.
Make the handler either INTR_MPSAFE or INTR_FAST (it doesn't matter
for slow devices like psm). Put all the rest of what was in the
interrupt handler in non-MPSAFE code (except where it accesses data
shared with the interrupt handler) so that all of this code and its
closure doesn't need to be made MPSAFE. This method is what the sio
driver uses in -current, sort of accidentally. sio's SWI handler and
all of the tty subsystem are not
Re: the PS/2 mouse problem
Morten Johansen wrote: Scott Long wrote: One thought that I had was to make psmintr() be INTR_FAST. I need to stare at the code some more to fully understand it, but it looks like it wouldn't be all that hard to do. Basically just use the interrupt handler to pull all of the data out of the hardware and into a ring buffer in memory, and then a fast taskqueue to process that ring buffer. It would at least answer the question of whether the observed problems are due to ithread latency. And if done right, no locks would be needed in psmintr(). Scott I can reproduce the problem consistently on my machine, by moving the mouse around, while executing e.g this command in a xterm: dd if=/dev/zero of=test bs=32768 count=4000; sync; sync; sync when the sync'ing sets in the mouse attacks. It is very likely due to interrupt latency. I'd be happy to test any clever patches. Morten Wow. You are completly right! By using a MTX_SPIN mutex instead, and marking the interrupt handler INTR_MPSAFE | INTR_FAST, my problem goes away. I am no longer able to reproduce the mouse attack. I have not noticed any side-effects of this. Could there be any? I will file a PR with an updated patch, unless you think it's a better idea to rearrange the driver. Probably the locking could be done better anyway. Morten ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
the PS/2 mouse problem
Robert Watson wrote:
There's been some speculation that the PS/2 mouse problem could be due to
high interrupt latency for non-fast interrupt handlers (especially ones
not MPSAFE) in 5.x. I think it would make a lot of sense for us to push
Giant off both the PS/2 mouse and syscons interrupt handlers in the near
future. For syscons, this would also improve the reliability of dropping
into the debugger from a non-serial console.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
Hi,
I tried pushing Giant out of psm a while ago, a patch is attached.
It did not help, but probably eases contention on Giant a bit.
psm gets a lot of interrupts.
I am still seeing occasional weirdness from the mouse.
It freezes then goes berserk (moving and triggering events) for a few
seconds.
The kernel says:
psmintr: delay too long; resetting byte count
(I was wrong about the message in a previous mail)
This actually happens more often in -stable than in -current.
moused or not does not make a difference.
The latest SCHED_ULE and interrupt changes, have not fixed this problem.
Otherwise, FreeBSD 5-current is the best OS I have ever run.
Morten Johansen
--- psm-0.c Wed Nov 5 19:30:09 2003
+++ psm.c Wed Nov 5 20:23:41 2003
@@ -129,6 +129,11 @@ __FBSDID($FreeBSD: src/sys/isa/psm.c,v
#define PSM_NBLOCKIO(dev) (minor(dev) 1)
#define PSM_MKMINOR(unit,block)(((unit) 1) | ((block) ? 0:1))
+#define PSM_MTX_INIT(_sc, name) mtx_init(_sc-psm_mtx, name, NULL, MTX_DEF)
+#define PSM_MTX_DESTROY(_sc)mtx_destroy(_sc-psm_mtx)
+#define PSM_LOCK(_sc) mtx_lock((_sc)-psm_mtx)
+#define PSM_UNLOCK(_sc) mtx_unlock((_sc)-psm_mtx)
+
/* ring buffer */
typedef struct ringbuf {
int count; /* # of valid elements in the buffer */
@@ -160,9 +165,10 @@ struct psm_softc { /* Driver status inf
int syncerrors;
struct timeval inputtimeout;
int watchdog; /* watchdog timer flag */
-struct callout_handle callout; /* watchdog timer call out */
+struct callout callout;/* watchdog timer call out */
dev_tdev;
dev_tbdev;
+struct mtx psm_mtx;
};
static devclass_t psm_devclass;
#define PSM_SOFTC(unit)((struct psm_softc*)devclass_get_softc(psm_devclass,
unit))
@@ -250,6 +256,7 @@ static int doinitialize(struct psm_softc
static int doopen(struct psm_softc *, int);
static int reinitialize(struct psm_softc *, int);
static char *model_name(int);
+static void _psmintr(void *);
static void psmintr(void *);
static void psmtimeout(void *);
@@ -769,7 +776,7 @@ doopen(struct psm_softc *sc, int command
/* start the watchdog timer */
sc-watchdog = FALSE;
-sc-callout = timeout(psmtimeout, (void *)(uintptr_t)sc, hz*2);
+callout_reset(sc-callout, hz*2, psmtimeout, (void *)(uintptr_t)sc);
return (0);
}
@@ -779,17 +786,16 @@ reinitialize(struct psm_softc *sc, int d
{
int err;
int c;
-int s;
/* don't let anybody mess with the aux device */
if (!kbdc_lock(sc-kbdc, TRUE))
return (EIO);
-s = spltty();
+PSM_LOCK(sc);
/* block our watchdog timer */
sc-watchdog = FALSE;
-untimeout(psmtimeout, (void *)(uintptr_t)sc, sc-callout);
-callout_handle_init(sc-callout);
+callout_stop(sc-callout);
+callout_init(sc-callout, CALLOUT_MPSAFE);
/* save the current controller command byte */
empty_both_buffers(sc-kbdc, 10);
@@ -804,7 +810,7 @@ reinitialize(struct psm_softc *sc, int d
KBD_DISABLE_KBD_PORT | KBD_DISABLE_KBD_INT
| KBD_ENABLE_AUX_PORT | KBD_DISABLE_AUX_INT)) {
/* CONTROLLER ERROR */
- splx(s);
+ PSM_UNLOCK(sc);
kbdc_lock(sc-kbdc, FALSE);
log(LOG_ERR, psm%d: unable to set the command byte (reinitialize).\n,
sc-unit);
@@ -834,7 +840,7 @@ reinitialize(struct psm_softc *sc, int d
err = ENXIO;
}
}
-splx(s);
+PSM_UNLOCK(sc);
/* restore the driver state */
if ((sc-state PSM_OPEN) (err == 0)) {
@@ -1225,9 +1231,10 @@ psmattach(device_t dev)
if (sc == NULL)/* shouldn't happen */
return (ENXIO);
+PSM_MTX_INIT(sc, device_get_nameunit(dev));
/* Setup initial state */
sc-state = PSM_VALID;
-callout_handle_init(sc-callout);
+callout_init(sc-callout, CALLOUT_MPSAFE);
/* Setup our interrupt handler */
rid = KBDC_RID_AUX;
@@ -1235,7 +1242,7 @@ psmattach(device_t dev)
RF_SHAREABLE | RF_ACTIVE);
if (sc-intr == NULL)
return (ENXIO);
-error = bus_setup_intr(dev, sc-intr, INTR_TYPE_TTY, psmintr, sc, sc-ih);
+error = bus_setup_intr(dev, sc-intr, INTR_TYPE_TTY | INTR_MPSAFE, psmintr, sc,
sc-ih);
if (error) {
bus_release_resource(dev, SYS_RES_IRQ, rid, sc-intr);
return (error
Re: the PS/2 mouse problem
One thought that I had was to make psmintr() be INTR_FAST. I need to stare at the code some more to fully understand it, but it looks like it wouldn't be all that hard to do. Basically just use the interrupt handler to pull all of the data out of the hardware and into a ring buffer in memory, and then a fast taskqueue to process that ring buffer. It would at least answer the question of whether the observed problems are due to ithread latency. And if done right, no locks would be needed in psmintr(). Scott On Wed, 5 Nov 2003, Morten Johansen wrote: Robert Watson wrote: There's been some speculation that the PS/2 mouse problem could be due to high interrupt latency for non-fast interrupt handlers (especially ones not MPSAFE) in 5.x. I think it would make a lot of sense for us to push Giant off both the PS/2 mouse and syscons interrupt handlers in the near future. For syscons, this would also improve the reliability of dropping into the debugger from a non-serial console. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories Hi, I tried pushing Giant out of psm a while ago, a patch is attached. It did not help, but probably eases contention on Giant a bit. psm gets a lot of interrupts. I am still seeing occasional weirdness from the mouse. It freezes then goes berserk (moving and triggering events) for a few seconds. The kernel says: psmintr: delay too long; resetting byte count (I was wrong about the message in a previous mail) This actually happens more often in -stable than in -current. moused or not does not make a difference. The latest SCHED_ULE and interrupt changes, have not fixed this problem. Otherwise, FreeBSD 5-current is the best OS I have ever run. Morten Johansen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [acpi-jp 1246] ACPI and PS/2 mouse problem
John Baldwin wrote: And do you have the following line in /boot/device.hints? hint.psm.0.irq=12 i have ibm 570e, with the same PS/2 mouse problem, Ohh. worse.. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x3a fault code = supervisor read, page not present instruction pointer= 0x8:0xc0268092 stack pointer = 0x10:0xcd1dc948 frame pointer = 0x10:0xcd1dc948 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= 50 (sysctl) trap number= 12 \|/ \|/ @'/ .. \`@ /_| \__/ |_\ \__U_/ Do you have a debug kernel, if so, can you do 'gdb -k kernel.debug' in your sys/i386/compile/FOO directory and then do 'l *0xc0268092' to see what source line it died on. It's a NULL pointer dereference (as can be seen from the John, please ignore my previous report since i made a mistake using a broken kernel. i was first trying the broken PS/2 mouse, and then using another kernel to see the diff, i mixed them togather. sorry. -- // Donny To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1255] Re: ACPI and PS/2 mouse problem
Hi, I have the same laptop but a different problem, with today kernel. The following is copied by hand, no serial console at home: wait: panic: free: address 0xcbf5e5fe db trace panic(...) at panic+0xb6 free(...) at free+0x32 AcpiOsFree(...) at AcpiOsFree+0x11 AcpiExCopyStringToString(...) at AcpiExCopyStringToString+0x4d Yes, this is already analyzed in http://home.jp.FreeBSD.org/cgi-bin/showmail/acpi-jp/1239 Try following patch. This fix will be appear in next Intel ACPICA snapshot release. Index: dsobject.c === RCS file: /home/ncvs/src/sys/contrib/dev/acpica/dsobject.c,v retrieving revision 1.1.1.9 diff -u -r1.1.1.9 dsobject.c --- dsobject.c 26 Aug 2001 22:28:16 - 1.1.1.9 +++ dsobject.c 3 Sep 2001 11:45:49 - @@ -558,6 +558,7 @@ break; } +ObjDesc-Common.Flags |= AOPOBJ_STATIC_POINTER; return (AE_OK); } Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1246] ACPI and PS/2 mouse problem
Thank you for your report. On Sat, Sep 08, 2001 at 12:15:59AM +0900, Kazutaka YOKOTA wrote: Please send me the entire dmesg output after you boot the system with boot -v at the loader prompt. ok. And do you have the following line in /boot/device.hints? hint.psm.0.irq=12 yes. I tried with and without some lines in /boot/device.hints. attached outputs is with the following hints: hint.atkbd.0.at=atkbdc hint.atkbd.0.irq=1 hint.atkbd.0.flags=0x1 hint.psm.0.at=atkbdc hint.psm.0.irq=12 hint.vga.0.at=isa hint.sc.0.at=isa hint.sc.0.flags=0x100 hint.vt.0.at=isa hint.pmtimer.0.at=isa hint.spic.0.at=isa hint.spic.0.port=0x10a0 hint.acpi.0.disable=1 Your forgot to put the following lines in device.hints. hint.atkbdc.0.at=isa hint.atkbdc.0.port=0x60 See /sys/i386/conf/GENERIC.hints. However, there definitely are some strange things about ACPI and PnP BIOS in your machine... Your first dmesg: the acpi module is enabled. acpi0: SONY Z1 on motherboard Timecounter ACPI frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x8008-0x800b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_button0: Power Button on acpi0 acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0 [...] atspeaker0 port 0x61 on acpi0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 ~ atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d atkbd1: unable to allocate IRQ psm0: unable to allocate IRQ atkbd1: unable to allocate IRQ psm0: current command byte:0047 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model GlidePoint, device ID 0-00, 2 buttons psm0: config:6000, flags:, packet size:3 psm0: syncmask:c0, syncbits:00 psmcpnp0 irq 12 on acpi0 The PS/2 mouse is detected. But, the AT keyboard driver is assigned with port resources 0x64 and 0x60; the order should normally be 0x60, then 0x64... Your second dmesg: the acpi module is disabled. As you don't have hint.atkbdc.0.at=isa hint.atkbdc.0.port=0x60 in device hints, the kernel tried to attach the keyboard controller, keyboard and PS/2 mouse based on the PnP BIOS information. This should normally work, despite the missing above lines in device.hints, because the information supplied by the PnP BIOS is supporsed to be correct. But, see below. [...] pnpbios: 17 devices, largest 210 bytes PNP0c02: adding fixed memory32 range 0xfff8-0x, size=0x8 [...] pnpbios: handle 15 device ID SNY7001 (0170d9cd) PNP0401: adding io range 0x378-0x37f, size=0x8, align=0x1 PNP0401: adding io range 0x778-0x77f, size=0x8, align=0x1 PNP0401: adding irq mask 0x80 PNP0401: adding dma mask 0x8 pnpbios: handle 18 device ID PNP0401 (0104d041) pnpbios: handle 20 device ID PNP0f13 (130fd041) ~~~ This is the PS/2 mouse reported by the PnP BIOS. It should be assigned with the irq mask 0x1000. But it's missing here! atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 irq 1 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d atkbd1: unable to allocate IRQ psm0: unable to allocate IRQ [...] (The above failure is expected, and you can ignore.) psmcpnp0: PS/2 mouse port on isa0 You should see psm0: PS/2 mouse irq 12 on atkbdc0 psmcpnp0: PS/2 mouse port irq 12 on isa0 at this point. But, because the irq was not assigned to the PS/2 mouse node earlier by the PnP BIOS, the mouse failed to attach. I have never seen this failure before ;-( I will think about what I can do... Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1246] ACPI and PS/2 mouse problem
On Sat, Sep 08, 2001 at 07:32:17PM +0900, Kazutaka YOKOTA wrote: Your forgot to put the following lines in device.hints. hint.atkbdc.0.at=isa hint.atkbdc.0.port=0x60 See /sys/i386/conf/GENERIC.hints. no, I didn't forget. It wasn't required before now and I had 1 string less in unknown devices :) anyway, I've added this to device.hints and now mouse works. There is dmesg diff: --- dmesg.noacpiSat Sep 8 11:02:22 2001 +++ dmesg.noacpi.after Sat Sep 8 15:28:23 2001 @@ -3,8 +3,8 @@ The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #46: Sat Sep 8 10:26:49 MSD 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/VAIO -Calibrating clock(s) ... TSC clock: 496308852 Hz, i8254 clock: 1193183 Hz -Timecounter i8254 frequency 1193183 Hz +Calibrating clock(s) ... TSC clock: 496305810 Hz, i8254 clock: 1193175 Hz +Timecounter i8254 frequency 1193175 Hz CPU: Pentium III/Pentium III Xeon/Celeron (496.31-MHz 686-class CPU) Origin = GenuineIntel Id = 0x681 Stepping = 1 Features=0x387f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE @@ -314,6 +314,16 @@ bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff +atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 +atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 +kbd0 at atkbd0 +kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d +atkbd1: unable to allocate IRQ +psm0: current command byte:0047 +psm0: PS/2 Mouse irq 12 on atkbdc0 +psm0: model GlidePoint, device ID 0-00, 2 buttons +psm0: config:6000, flags:, packet size:3 +psm0: syncmask:c0, syncbits:00 pmtimer0 on isa0 sc1: no video adapter found. sc1: System console failed to probe at flags 0x100 on isa0 @@ -323,12 +333,8 @@ isa_probe_children: probing PnP devices unknown: PNP0c02 can't assign resources unknown: PNP0c02 at port 0x398-0x399,0x4d0-0x4d1,0x8000-0x804f,0x1040-0x104f iomem 0xfff8-0x,0xfff7f600-0xfff7 on isa0 -atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 irq 1 on isa0 -atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 -kbd0 at atkbd0 -kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d -atkbd1: unable to allocate IRQ -psm0: unable to allocate IRQ +unknown: PNP0303 can't assign resources +unknown: PNP0303 at port 0x60 on isa0 atspeaker0: AT speaker at port 0x61 on isa0 unknown: PNP0c02 can't assign resources unknown: PNP0c02 at iomem 0xdc000-0xd on isa0 -- bye Juriy Goloveshkin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1246] ACPI and PS/2 mouse problem
Please send me the entire dmesg output after you boot the system with boot -v at the loader prompt. And do you have the following line in /boot/device.hints? hint.psm.0.irq=12 Kazu I don't know why, but NOW I have broken PS/2 mouse _without_ acpi module :( VAIO Z505HS. atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 irq 1 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d atkbd1: unable to allocate IRQ psm0: unable to allocate IRQ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1247] Re: ACPI and PS/2 mouse problem
I'm not sure exactly what to do here. These resources contain information we need to know about where we cannot put PnP devices. But if we feed the information into our current resource manager, we end up with conflicts with existing devices. For the moment, I've changed the code to allocate IRQs shared. The PS/2 mouse driver should do the same. I'm still trying to work out what we can and cannot depend on here. 8( The psm driver has been updated to share the irq 12, as of rev 1.37. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1246] ACPI and PS/2 mouse problem
Kazutaka YOKOTA wrote: Please send me the entire dmesg output after you boot the system with boot -v at the loader prompt. And do you have the following line in /boot/device.hints? hint.psm.0.irq=12 i have ibm 570e, with the same PS/2 mouse problem, Ohh. worse.. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x3a fault code = supervisor read, page not present instruction pointer= 0x8:0xc0268092 stack pointer = 0x10:0xcd1dc948 frame pointer = 0x10:0xcd1dc948 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= 50 (sysctl) trap number= 12 \|/ \|/ @'/ .. \`@ /_| \__/ |_\ \__U_/ (ps. funny, but i'v run out of humor booting like this... ) panic: page fault syncing disks... done uptime: 5s pccbb0: pccbb_power: CARD_VCC_0V and CARD_VPP_0V [44] pccbb1: pccbb_power: CARD_VCC_0V and CARD_VPP_0V [44] Automatic reboot in 15 seconds - press a key on the console to abort -- // Donny To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1246] ACPI and PS/2 mouse problem
On 07-Sep-01 Donny Lee wrote: Kazutaka YOKOTA wrote: Please send me the entire dmesg output after you boot the system with boot -v at the loader prompt. And do you have the following line in /boot/device.hints? hint.psm.0.irq=12 i have ibm 570e, with the same PS/2 mouse problem, Ohh. worse.. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x3a fault code = supervisor read, page not present instruction pointer= 0x8:0xc0268092 stack pointer = 0x10:0xcd1dc948 frame pointer = 0x10:0xcd1dc948 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= 50 (sysctl) trap number= 12 \|/ \|/ @'/ .. \`@ /_| \__/ |_\ \__U_/ (ps. funny, but i'v run out of humor booting like this... ) panic: page fault Do you have a debug kernel, if so, can you do 'gdb -k kernel.debug' in your sys/i386/compile/FOO directory and then do 'l *0xc0268092' to see what source line it died on. It's a NULL pointer dereference (as can be seen from the small fault virtual address) so seeing the source line will probably make it rather obvious. Also, compiling ddb into the kernel and getting a traceback would help, too. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1246] ACPI and PS/2 mouse problem
On Thu, Sep 06, 2001 at 08:51:44PM +0900, Kazutaka YOKOTA wrote: I don't know why, but NOW I have broken PS/2 mouse _without_ acpi module :( VAIO Z505HS. atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 irq 1 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d atkbd1: unable to allocate IRQ psm0: unable to allocate IRQ As reported in this list by several people, you may be seeing that your PS/2 mouse is not detected after the recent ACPI update. This seems to be caused by ACPI in some BIOS assigns IRQ 12 (mouse interrupt) to both the PS/2 mouse device node and the system reserved resource node. To see if this is to be your case, put the following line in /boot/device.hints and reboot. debug.acpi.disable=sysresource If this brings your mouse back, I recommend you to keep that line there until the proper fix is committed. If it doesn't solve the problem, there must be other causes ;-( You had better contact the FreeBSD ACPI developers ([EMAIL PROTECTED]) ML. Kazu PS: I am going to commit some update to the psm driver shortly. But, that alone won't fix the problem. Sorry... -- bye Juriy Goloveshkin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ACPI and PS/2 mouse problem
As reported in this list by several people, you may be seeing that your PS/2 mouse is not detected after the recent ACPI update. This seems to be caused by ACPI in some BIOS assigns IRQ 12 (mouse interrupt) to both the PS/2 mouse device node and the system reserved resource node. To see if this is to be your case, put the following line in /boot/device.hints and reboot. debug.acpi.disable=sysresource If this brings your mouse back, I recommend you to keep that line there until the proper fix is committed. If it doesn't solve the problem, there must be other causes ;-( You had better contact the FreeBSD ACPI developers ([EMAIL PROTECTED]) ML. Kazu PS: I am going to commit some update to the psm driver shortly. But, that alone won't fix the problem. Sorry... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1246] ACPI and PS/2 mouse problem
Thanks Yokota-san for tracking down the problem.
As reported in this list by several people, you may be seeing that
your PS/2 mouse is not detected after the recent ACPI update.
This seems to be caused by ACPI in some BIOS assigns IRQ 12 (mouse
interrupt) to both the PS/2 mouse device node and the system reserved
resource node.
And if such a problem was found, please send ACPI data with the
report. This is very useful info. for our debugging.
To get ACPI data,
# acpidump -o foo.dsdt foo.asl
and send both files to acpi-jp@. See also acpidump(8).
To see if this is to be your case, put the following line in
/boot/device.hints and reboot.
debug.acpi.disable=sysresource
I personally, don't have enough time to hack the code for now (sorry),
but I think that newly added `placeholders' code causes the problem
for my first impression.
for (i = 0; i 100; i++) {
rid = i;
res = bus_alloc_resource(dev, SYS_RES_IOPORT, rid, 0, ~0, 1, 0);
rid = i;
res = bus_alloc_resource(dev, SYS_RES_MEMORY, rid, 0, ~0, 1, 0);
rid = i;
res = bus_alloc_resource(dev, SYS_RES_IRQ, rid, 0, ~0, 1, 0);
}
Mike, do you have any idea on this?
Anyway, Yokota-san thank you very much for finding a workaround.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1247] Re: ACPI and PS/2 mouse problem
I personally, don't have enough time to hack the code for now (sorry),
but I think that newly added `placeholders' code causes the problem
for my first impression.
Yes; this is something that I'm not happy about. It looks like these
resources are being badly abused by vendors as hints for allocation of
fresh resources, rather than truly reflecting the system configuration.
for (i = 0; i 100; i++) {
rid = i;
res = bus_alloc_resource(dev, SYS_RES_IOPORT, rid, 0, ~0, 1, 0);
rid = i;
res = bus_alloc_resource(dev, SYS_RES_MEMORY, rid, 0, ~0, 1, 0);
rid = i;
res = bus_alloc_resource(dev, SYS_RES_IRQ, rid, 0, ~0, 1, 0);
}
Mike, do you have any idea on this?
I'm not sure exactly what to do here. These resources contain information
we need to know about where we cannot put PnP devices. But if we feed the
information into our current resource manager, we end up with conflicts
with existing devices.
For the moment, I've changed the code to allocate IRQs shared. The
PS/2 mouse driver should do the same. I'm still trying to work out
what we can and cannot depend on here. 8(
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
