Robert Crocombe wrote:
> On 11/27/06, Stefan Richter <[EMAIL PROTECTED]> wrote:
>> Posted writes are still enabled. phys_dma=0 disables only the physical
>> response unit.
...
> What I need is for write requests directed to
> address 0 to be directed to the asynchronous unit so that I can treat
>
On 11/27/06, Stefan Richter <[EMAIL PROTECTED]> wrote:
Posted writes are still enabled. phys_dma=0 disables only the physical
response unit. You have to change the source if you want to disable
posted writes. See the top of ohci_initialize. Should this be a module
load parameter too?
Er. I
On 11/27/06, Stefan Richter [EMAIL PROTECTED] wrote:
Posted writes are still enabled. phys_dma=0 disables only the physical
response unit. You have to change the source if you want to disable
posted writes. See the top of ohci_initialize. Should this be a module
load parameter too?
Er. I
Robert Crocombe wrote:
On 11/27/06, Stefan Richter [EMAIL PROTECTED] wrote:
Posted writes are still enabled. phys_dma=0 disables only the physical
response unit.
...
What I need is for write requests directed to
address 0 to be directed to the asynchronous unit so that I can treat
them as
Robert Crocombe wrote:
...
> Nov 27 13:06:37 spanky kernel: ohci1394: fw-host1: IntEvent: 00020010
busReset + RQPkt (packet sent)
...
> Nov 27 13:06:37 spanky kernel: ohci1394: fw-host1: IntEvent: 0001
selfIDcomplete
...
> Nov 27 13:06:40 spanky kernel: ohci1394: fw-host1: IntEventClear
>
Robert Crocombe wrote:
this is in 2.6.16-rt29 which has proved to be the easiest to provoke.
I actually couldn't get 2.6.18 to break earlier this morning (few
hundred resets).
Okay, I got the problem to occur again with 2.6.18. I will attach my
config in case you wish to scrutinize for any
I wrote:
> Question to others:
>
> ohci1394.c::ohci_irq_handler() is taking a per-host spinlock around some
> register reads and writes, particularly:
> ...
> spin_lock_irqsave(>event_lock, flags);
> event = reg_read(ohci, OHCI1394_IntEventClear);
> reg_write(ohci,
Robert Crocombe wrote:
> Okay, so the code looks like this now:
>
> DBGMSG("PhyReqFilter=%08x%08x",
>reg_read(ohci,OHCI1394_PhyReqFilterHiSet),
>reg_read(ohci,OHCI1394_PhyReqFilterLoSet));
>
>
On 11/27/06, Stefan Richter <[EMAIL PROTECTED]> wrote:
But perhaps more importantly, how are the IRQs distributed?
# cat /proc/interrupts
This is almost right after boot. I generated about 40 bus resets just
to stir things up a little:
CPU0 CPU1 CPU2 CPU3
0:
On 11/27/2006 4:39 PM, Robert Crocombe wrote:
> On 11/22/06, Stefan Richter <[EMAIL PROTECTED]> wrote:
>> One thing you could try next is to add a debug logging macro which
>> prints the contents of OHCI1394_IntEventClear, OHCI1394_IntEventSet, and
>> OHCI1394_IntMaskSet, right after ohci1394's
On 11/22/06, Stefan Richter <[EMAIL PROTECTED]> wrote:
One thing you could try next is to add a debug logging macro which
prints the contents of OHCI1394_IntEventClear, OHCI1394_IntEventSet, and
OHCI1394_IntMaskSet, right after ohci1394's call to
hpsb_selfid_complete. (I'm merely poking in the
On 11/22/06, Stefan Richter [EMAIL PROTECTED] wrote:
One thing you could try next is to add a debug logging macro which
prints the contents of OHCI1394_IntEventClear, OHCI1394_IntEventSet, and
OHCI1394_IntMaskSet, right after ohci1394's call to
hpsb_selfid_complete. (I'm merely poking in the
On 11/27/2006 4:39 PM, Robert Crocombe wrote:
On 11/22/06, Stefan Richter [EMAIL PROTECTED] wrote:
One thing you could try next is to add a debug logging macro which
prints the contents of OHCI1394_IntEventClear, OHCI1394_IntEventSet, and
OHCI1394_IntMaskSet, right after ohci1394's call to
On 11/27/06, Stefan Richter [EMAIL PROTECTED] wrote:
But perhaps more importantly, how are the IRQs distributed?
# cat /proc/interrupts
This is almost right after boot. I generated about 40 bus resets just
to stir things up a little:
CPU0 CPU1 CPU2 CPU3
0:
Robert Crocombe wrote:
Okay, so the code looks like this now:
DBGMSG(PhyReqFilter=%08x%08x,
reg_read(ohci,OHCI1394_PhyReqFilterHiSet),
reg_read(ohci,OHCI1394_PhyReqFilterLoSet));
I wrote:
Question to others:
ohci1394.c::ohci_irq_handler() is taking a per-host spinlock around some
register reads and writes, particularly:
...
spin_lock_irqsave(ohci-event_lock, flags);
event = reg_read(ohci, OHCI1394_IntEventClear);
reg_write(ohci,
Robert Crocombe wrote:
this is in 2.6.16-rt29 which has proved to be the easiest to provoke.
I actually couldn't get 2.6.18 to break earlier this morning (few
hundred resets).
Okay, I got the problem to occur again with 2.6.18. I will attach my
config in case you wish to scrutinize for any
Robert Crocombe wrote:
...
Nov 27 13:06:37 spanky kernel: ohci1394: fw-host1: IntEvent: 00020010
busReset + RQPkt (packet sent)
...
Nov 27 13:06:37 spanky kernel: ohci1394: fw-host1: IntEvent: 0001
selfIDcomplete
...
Nov 27 13:06:40 spanky kernel: ohci1394: fw-host1: IntEventClear
18 matches
Mail list logo
