ohci1396_dma=early nogo on an imac?

ohci1396_dma=early nogo on an imac?

[Justin P. Mattock]

Seems the macbook shows the init ohci1394_dma
activating, but using this on an imac has no affects.
is this device supported yet or is this still in the process of being
developed?(event though the imac is 1394 800 port).

At the moment my machine boots up 2.6.30.4 but will not bootup
the latest git. If the early dma option is possible with the imac9,1
I can send out a post with the error, and see if somebody might know.
(but if this isn't possible then Ill take the 40$
for the cable and and spend it on beer)...

Justin P. Mattock

Re: ohci1396_dma=early nogo on an imac?

[Stefan Richter]

Justin P. Mattock wrote:
> Seems the macbook shows the init ohci1394_dma
> activating, but using this on an imac has no affects.
> is this device supported yet or is this still in the process of being
> developed?(event though the imac is 1394 800 port).
> 
> At the moment my machine boots up 2.6.30.4 but will not bootup
> the latest git. If the early dma option is possible with the imac9,1
> I can send out a post with the error, and see if somebody might know.
> (but if this isn't possible then Ill take the 40$
> for the cable and and spend it on beer)...

init_ohci1394_dma is supposed to work on all OHCI-1394 compliant
controllers.  This includes all FireWire controllers in all iMac models
ever made.  (However, init_ohci1394_dma's initialization is a
trimmed-down version of ohci1394's, and is much much less widely tested
than the ohci1394 driver, hence there may be things which work in the
latter but not quite in the former.  If so, it should be fixed.)

But note that there is an important limitation in init_ohci1394_dma:
After it opened the DMA filters, there must be no subsequent FireWire
bus reset.  When a bus reset happens, the controller immediately filters
everything again ( = disallows remote DMA).  To compensate for that,
init_ohci1394_dma would have to have an IRQ handler which handles bus
reset IRQ events.  (And the CPU must not lock up before you need it to
handle the IRQ.)

Causes for a bus reset are:
  - Something was plugged out or into the bus.
  - One of the nodes on the bus changed its configuration (e.g.
    a disk enclosure finished spinning up its drive mechanism after
    power-on).
  - One of the nodes on the bus (the one which volunteers to be the
    so-called isochronous resource manager or bus manager) resets
    the bus to enable or optimize some bus functions.
To avoid all this, its best if you only have a single other node (as
debugger console) plugged in, have it already powered on and running the
1394 driver stack at the moment when your test PC starts
init_ohci1394_dma, you use the old ieee1394 + ohci1394 + raw1394 drivers
on the debugger console, and set ieee1394's disable_irm=1 parameter
there (disable isochronous resource manager).  The new replacement
drivers firewire-core + firewire-ohci don't have such a parameter, i.e.
always run some bus manager functions which might get in the way of
remote DMA to an init_ohci1394_dma running node.
-- 
Stefan Richter
-=====-==--= =--- =---=
http://arcgraph.de/sr/

Re: ohci1396_dma=early nogo on an imac?

[Justin Mattock]

On Mon, Aug 17, 2009 at 8:07 AM, Stefan
Richter<stefanr@s5r6.in-berlin.de> wrote:
> Justin P. Mattock wrote:
>> Seems the macbook shows the init ohci1394_dma
>> activating, but using this on an imac has no affects.
>> is this device supported yet or is this still in the process of being
>> developed?(event though the imac is 1394 800 port).
>>
>> At the moment my machine boots up 2.6.30.4 but will not bootup
>> the latest git. If the early dma option is possible with the imac9,1
>> I can send out a post with the error, and see if somebody might know.
>> (but if this isn't possible then Ill take the 40$
>> for the cable and and spend it on beer)...
>
> init_ohci1394_dma is supposed to work on all OHCI-1394 compliant
> controllers.  This includes all FireWire controllers in all iMac models
> ever made.  (However, init_ohci1394_dma's initialization is a
> trimmed-down version of ohci1394's, and is much much less widely tested
> than the ohci1394 driver, hence there may be things which work in the
> latter but not quite in the former.  If so, it should be fixed.)
>
> But note that there is an important limitation in init_ohci1394_dma:
> After it opened the DMA filters, there must be no subsequent FireWire
> bus reset.  When a bus reset happens, the controller immediately filters
> everything again ( = disallows remote DMA).  To compensate for that,
> init_ohci1394_dma would have to have an IRQ handler which handles bus
> reset IRQ events.  (And the CPU must not lock up before you need it to
> handle the IRQ.)
>
> Causes for a bus reset are:
>  - Something was plugged out or into the bus.
>  - One of the nodes on the bus changed its configuration (e.g.
>    a disk enclosure finished spinning up its drive mechanism after
>    power-on).
>  - One of the nodes on the bus (the one which volunteers to be the
>    so-called isochronous resource manager or bus manager) resets
>    the bus to enable or optimize some bus functions.
> To avoid all this, its best if you only have a single other node (as
> debugger console) plugged in, have it already powered on and running the
> 1394 driver stack at the moment when your test PC starts
> init_ohci1394_dma, you use the old ieee1394 + ohci1394 + raw1394 drivers
> on the debugger console, and set ieee1394's disable_irm=1 parameter
> there (disable isochronous resource manager).  The new replacement
> drivers firewire-core + firewire-ohci don't have such a parameter, i.e.
> always run some bus manager functions which might get in the way of
> remote DMA to an init_ohci1394_dma running node.
> --
> Stefan Richter
> -=====-==--= =--- =---=
> http://arcgraph.de/sr/
>

Thanks for the help.
I went out to apple and got the cable.
(not so bad 30$)

anyways I have  ieee1394 + ohci1394 + raw1394
loading as modules on both machines.

when using firescope I do this:
 sudo ./firescope -Aut /home/name/debug/System.map-2.6.30.4
(2.6.30.4 as a test until this is working).

seems I might have something missing.
in dmesg I see this:


[  660.190134] ieee1394: Current remote IRM is not 1394a-2000
compliant, resetting...
[  660.510613] ieee1394: Speed probe of node 0-00:1023 yields S400
[  661.060137] ieee1394: Current remote IRM is not 1394a-2000
compliant, resetting...
[  661.380418] ieee1394: Speed probe of node 0-00:1023 yields S400
[  661.920142] ieee1394: Current remote IRM is not 1394a-2000
compliant, resetting...
[  662.240405] ieee1394: Speed probe of node 0-00:1023 yields S400
[  662.790138] ieee1394: Current remote IRM is not 1394a-2000
compliant, resetting...
[  663.110416] ieee1394: Speed probe of node 0-00:1023 yields S400
[  663.650100] ieee1394: Current remote IRM is not 1394a-2000
compliant, resetting...
[  663.970457] ieee1394: Speed probe of node 0-00:1023 yields S400
[  664.510146] ieee1394: Current remote IRM is not 1394a-2000
compliant, resetting...
[  664.830454] ieee1394: Speed probe of node 0-00:1023 yields S400

keeps going.

with firescope I get this:

  sudo ./firescope -Aut /home/name/debug/System.map-2.6.30.4
Port 0 (ohci1394) opened, 2 nodes detected
Loaded system.map </home/name/debug/System.map-2.6.30.4> <1493445> bytes
2 nodes available, local node is: 1
 0: ffc0, uuid: <err: 11>
 1: ffc1, uuid: ffe31900 7ed82afe [LOCAL]
remote read failed, addr=7d65b8remote read failed, addr=7d659ckernel
buffer at phys 7fffffff len 4294967295
Cannot allocate log_buf shadow of 4294967295 bytes
No kernel log buffer
No kernel log buffer
No kernel log buffer
(keeps going)

any ideas?


-- 
Justin P. Mattock

Re: ohci1396_dma=early nogo on an imac?

[Stefan Richter]

Justin Mattock wrote:
> [  660.190134] ieee1394: Current remote IRM is not 1394a-2000
> compliant, resetting...
...
> keeps going.

It's a bug in ieee1394.  http://bugzilla.kernel.org/show_bug.cgi?id=8403

Use the ieee1394 disable_irm=1 parameter on one or both nodes.  Perhaps 
firescope will then get going as well.
-- 
Stefan Richter
-=====-==--= =--- =---=
http://arcgraph.de/sr/

Re: ohci1396_dma=early nogo on an imac?

[Justin P. Mattock]

Stefan Richter wrote:
> Justin Mattock wrote:
>> [  660.190134] ieee1394: Current remote IRM is not 1394a-2000
>> compliant, resetting...
> ...
>> keeps going.
>
> It's a bug in ieee1394.  http://bugzilla.kernel.org/show_bug.cgi?id=8403
>
> Use the ieee1394 disable_irm=1 parameter on one or both nodes.  
> Perhaps firescope will then get going as well.
O.K. Thanks to you
using 2.6.30.4 I was able to log the boot message.
now I can see if I can grab the info on the stuckage that
im getting with the bad kernel.

The problem im seeing is if I use ohci1394_dma=early on the bad kernel
instantly Ill get a message on the screen saying:

PANIC: early exception 08 rip 246:10 error ffffffff8145ff15 cr2 0

if I don't use the boot param the system loads but half way through
ill get a message of

manually writing down:

[   0.655640] [<ffffffff81440c33>] panic+0x84/0x129
[   0.655883] [<ffffffff81063f96>]  do_exit+0x84/0x67e
[   0.656125] [<ffffffff81445044>] oops_end+0x9c/0xb7
[   0.656368] [<ffffffff81044a6c>] no_context+0x200/0x223
[   0.656611] [<ffffffff81442d3d>] ? __mutex_lock_slowpath+0x226/0x249
[   0.656848] [<ffffffff81044c36>] __bad_area_nosemaphore+0x1a7/0x1e1
[   0.657097] [<ffffffff81442b01>]? mutex_unlock+0x1c/0x32
[   0.657097] [<ffffffff811ce094>] ? inode_doinit_with_dentry+0x533/0x5be
[   0.657579] [<ffffffff81443ee0>] ? _spin_unlock+0x1c/0x32
[   0.657822] [<ffffffff81044c91>] bad_area_nosemaphore+0x2a/0x40
[   0.658066] [<ffffffff811ce149>] ? selinux_d_instantiate+0x2a/0x40
[   0.658309] [<ffffffff8144687d>] do_page_fault+0x192/0x2dd
[   0.658549] [<ffffffff814444cf>] page_fault+0x1f/0x30
[   0.658791] [<ffffffff8120e856>] ? strcmp+0x17/0x46
[   0.659040] [<ffffffff810b9ca0>] event_create_dir+0x49/0x37b
[   0.659276] [<ffffffff81696f0a>] ? event_trace_init+0x0/0x1a2
[   0.659519] [<ffffffff81697061>] event_trace_init+0x157/0x1a2
[   0.659762] [<ffffffff81696f0a>] ? event_trace_init+0x0/0x1a2
[   0.660008] [<ffffffff810091db>] do_one_initcall+0x65/0x14e
[   0.660251] [<ffffffff81140000>] ? proc_set_super+0x49/0x5d
[   0.660488] [<ffffffff8167ef53>] kernel_init+0x160/0x1cc
[   0.660731] [<ffffffff8102801a>] child_rip+0xa/0x20
[   0.660973] [<ffffffff8167edf3>] ? kernel_init+0x0/0x1cc
[   0.661220] [<ffffffff81028010>] ? child_rip+0x0/0x20


Justin P. Mattock

Re: ohci1396_dma=early nogo on an imac?

[Stefan Richter]

Justin P. Mattock wrote:
> The problem im seeing is if I use ohci1394_dma=early on the bad kernel
> instantly Ill get a message on the screen saying:
> 
> PANIC: early exception 08 rip 246:10 error ffffffff8145ff15 cr2 0

Hmm, as I am not familiar with anything related to early initialization, 
I have no idea what it means let alone what causes it.
-- 
Stefan Richter
-=====-==--= =--- =---=
http://arcgraph.de/sr/

Re: ohci1396_dma=early nogo on an imac?

[Justin P. Mattock]

Stefan Richter wrote:
> Justin P. Mattock wrote:
>> The problem im seeing is if I use ohci1394_dma=early on the bad kernel
>> instantly Ill get a message on the screen saying:
>>
>> PANIC: early exception 08 rip 246:10 error ffffffff8145ff15 cr2 0
>
> Hmm, as I am not familiar with anything related to early 
> initialization, I have no idea what it means let alone what causes it.
neither do I, at the moment I'll load
2.6.31-rc5 to see if I hit this, then
ill go through all of the commits up to rc6
if not ill have to start back with 2.6.30.4
and work my way up.

Justin P. Mattock

Re: ohci1396_dma=early nogo on an imac?

[Justin P. Mattock]

Stefan Richter wrote:
> Justin P. Mattock wrote:
>> The problem im seeing is if I use ohci1394_dma=early on the bad kernel
>> instantly Ill get a message on the screen saying:
>>
>> PANIC: early exception 08 rip 246:10 error ffffffff8145ff15 cr2 0
>
> Hmm, as I am not familiar with anything related to early 
> initialization, I have no idea what it means let alone what causes it.
alright, 2.6.31-rc5 works
(positive side is this is not far back in time).

Justin P. Mattock

Re: ohci1396_dma=early nogo on an imac?

[Justin P. Mattock]

Stefan Richter wrote:
> Justin Mattock wrote:
>> [  660.190134] ieee1394: Current remote IRM is not 1394a-2000
>> compliant, resetting...
> ...
>> keeps going.
>
> It's a bug in ieee1394.  http://bugzilla.kernel.org/show_bug.cgi?id=8403
>
> Use the ieee1394 disable_irm=1 parameter on one or both nodes.  
> Perhaps firescope will then get going as well.
Well I guess this is not going to work.
unable to use a boot param to initialize the dma=early option
plus if I'm able to do that, the system gets stuck before the modules
even activate.(man I got hosed...)

any other ideas on how to debug such a scenario?

Justin P. Mattock