linux1394-devel

Re: Multiple computers.

[<fir...@lo...>]

On Fri, 12 May 2000, Sebastien Rougeaux wrote:

> firewire-devel> We are trying to connect multiple computers using firewire for
> firewire-devel> a high speed network, and are having a some problems with the
> firewire-devel> driver.
> 
> firewire-devel> When I load the driver on the first machine it can see all of
> firewire-devel> the machines on the network.  I used 'testlibraw' to check.
> firewire-devel> Now when I load the drivers on the next machine 'testlibraw'
> firewire-devel> reports that it is the only machine on the network, but
> firewire-devel> 'testlibraw' on the first machine now shows comm between the
> firewire-devel> two.  Then when I try to load the drivers on the next machine,
> firewire-devel> it has the same problem as the second machine, but now the
> firewire-devel> second machine can see all of the nodes on the network.  The
> firewire-devel> keeps happening as I load the drivers on other machines.
> 
> firewire-devel> So is there a way to get the last machine to see all the
> firewire-devel> computers on the firewire network?
> 
> For some reason, the ohci driver sometimes doesn't work properly on the
> first 'insmod' after hardware reboot... have you tried to load it again
> a couple of times and see if things are improving ?

Well first off I am using the pcilynx driver, so I don't think that is the
problem.  I might have put down the wrong card in my previous email (could
not remember the exact card).  I did try your suggestion, but it did not
work, testlibraw still does not see any of the nodes on the network.

Thanks.

Judd Tracy
jt...@is...

Re: Receiving Video from other Computer

[<fra...@ya...>]

I have fix some Pbs with my virtal_VCR, by using the
last dvgrab
version 0.7 with a patch that can output files for
playdv (last
version). The movie is good (I can finally reconize
the dog). But playdv crash
at the end of the movie (segmentation fault), here is
the error
output :

** CRITICAL **: file bitstream.h: line 155
(bitstream_unget):
assertion `(num_bits <= 32) && (num_bits >0) &&
(!(data & (~mask)))'
failed.

Since xdv0.1 does not correctly decode my isochrone
flow, I
will try to build a direct line movie player which
will use dvgrab's
--dv algorithms option and the libdv codecs.

Currently, I have a ROM for IEEE 1394 boards. I have a
small program
that listen to FCP commands and try to respond like a
VCR
does. (Probably soon avaible)

But I do not support yet all commands described in the
AV/C Tape
Recorder / Player Subunit Specification.

In fact, I do not now exactly what is meaning of some
commands. 
And what are the main commands to support.

---

Franck Bonin


--- Andreas Micklei a écrit : > Hi,
> 
> On Thu, May 11, 2000 at 04:11:07PM +0200, Franck
> Bonin wrote:
> > So I have tryed to transform my PC-linux in an
> > TapeRecorderPlayer and
> > today I have succeded, by re-writing the
> ohci_csr_rom
> > located in the ohci1394.h file.
> 
> That is great. Right now I use the Linux 1394
> subsystem mainly for controlling
> a digital VCR. A virtual VCR on another Linux host
> would provide the perfect
> debugging tool for testing all those optional
> features that real VCRs do not
> implement yet.
> 
> If you have some more specific questions, feel free
> to ask. You can also send
> me your source if you like.
> 
> I would also like to see this thing run on an
> unmodofied Linux kernel. We
> would need an interface for changing the CSR ROM at
> run time, oder maybe the
> driver module should read the CSR rom from a file.
> The filename could be
> specified at module loading time as an optional
> parameter. What do the driver
> maintainers think of this idea?
> 
>    bye...
>          Andreas Micklei
> 


___________________________________________________________
Do You Yahoo!?
Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr

Re: Libraw1394 question

[Sebastien R. <Seb...@sy...>]

>>>>> "Mark" == Mark Knecht <mk...@co...> writes:

Mark> Sebastien, Without waiting for the ACK, or without waiting for the
Mark> response packet?  Mark

The ohci driver just queues the outgoing packets that it receives from the
subsystem into a fifo, and returns immediately after that, unless the
fifo is full, in which case it is put to sleep and it should output a
debug message (which I have never seen so far). No waiting for ack nor 
response packet (it is later signaled to the subsystem upon reception).

-- 
Sebastien Rougeaux
RSISE, The Australian National University

Re: Multiple computers.

[Sebastien R. <Seb...@sy...>]

>>>>> "firewire-devel" == firewire-devel  <fir...@se...> writes:

firewire-devel> We are trying to connect multiple computers using firewire for
firewire-devel> a high speed network, and are having a some problems with the
firewire-devel> driver.

firewire-devel> When I load the driver on the first machine it can see all of
firewire-devel> the machines on the network.  I used 'testlibraw' to check.
firewire-devel> Now when I load the drivers on the next machine 'testlibraw'
firewire-devel> reports that it is the only machine on the network, but
firewire-devel> 'testlibraw' on the first machine now shows comm between the
firewire-devel> two.  Then when I try to load the drivers on the next machine,
firewire-devel> it has the same problem as the second machine, but now the
firewire-devel> second machine can see all of the nodes on the network.  The
firewire-devel> keeps happening as I load the drivers on other machines.

firewire-devel> So is there a way to get the last machine to see all the
firewire-devel> computers on the firewire network?

For some reason, the ohci driver sometimes doesn't work properly on the
first 'insmod' after hardware reboot... have you tried to load it again
a couple of times and see if things are improving ?

-- 
Sebastien Rougeaux
RSISE, The Australian National University

RE: Receiving Video from other Computer

[Arne S. <ar...@sc...>]

libdv does both NTSC and PAL, if it is a recent version.

There is a flag in the DV data that identifies NTSC or PAL format. Check the 
playdv.c from libdv for more info. My dvgrab program also distinguishes NTSC 
and PAL, but it is not so straightforward there (I should really fix this).

Arne


-----Original Message-----
From:	Brian Murray [SMTP:br...@pr...]
Sent:	Friday, May 12, 2000 3:50 AM
To:	Franck Bonin
Cc:	lin...@li...
Subject:	Re: Receiving Video from other Computer


> I still have a problem concerning video decoding with
> xdv.
> I have attach a sample from the output gave by xdv
> (does anyone see the dog ?).

That looks exactly like an NTSC DV decoder fed with PAL DV material.
The 'DVGate Still' windoze app that came with my Vaio did the same
thing. Unfortunately it doesn't autodetect the video standard - it's
hard-coded with a registry setting!!! I'd hope that xdv can do
better than that (eventually).

I heard that libdv is currently NTSC only - maybe that explains it?

Otherwise nice work :)

Brian.



--
--
-----------------------------------
Brian Murray      Proximity Pty Ltd
http://www.proximity.com.au/~brian/
-----------------------------------

_______________________________________________
mailing list lin...@li...
http://lists.sourceforge.net/mailman/listinfo/linux1394-devel

Re: ethernet driver(bug report)

[Sebastien R. <Seb...@sy...>]

>>>>> "Franck" == =?iso-8859-1?q?Franck=20Bonin?=  <iso-8859-1> writes:

Franck> I may have found when exactly this bug append.  Just try this :

Franck> 1) insmod all the ieee 1394 modules (ieee1394, raw1394 & ohci1394)

Franck> 2) delmod all the 3 modules.

Franck> 3) generate a bus reset (by unplugging 1394 cables or insmoding ieee
Franck> 1394 modules on another node)

Franck> 4) re-insmod all the 3 modules...

Franck> 5) CRASH!

Franck> This bug is repetable as well with my ADS PYRO cards.

It should be fixed now in the latest CVS version. The reason for this
is that the board was not reset properly when unloading the driver.

Thanks a lot for your bug report,

-- 
Sebastien Rougeaux
RSISE, The Australian National University

Re: Receiving Video from other Computer

[<br...@pr...>]

> I still have a problem concerning video decoding with
> xdv.
> I have attach a sample from the output gave by xdv
> (does anyone see the dog ?).

That looks exactly like an NTSC DV decoder fed with PAL DV material.
The 'DVGate Still' windoze app that came with my Vaio did the same
thing. Unfortunately it doesn't autodetect the video standard - it's
hard-coded with a registry setting!!! I'd hope that xdv can do
better than that (eventually).

I heard that libdv is currently NTSC only - maybe that explains it?

Otherwise nice work :)

Brian.



--
--
-----------------------------------
Brian Murray      Proximity Pty Ltd
http://www.proximity.com.au/~brian/
-----------------------------------

Re: Receiving Video from other Computer

[Andreas M. <ami@@ivistar.de>]

Hi,

On Thu, May 11, 2000 at 04:11:07PM +0200, Franck Bonin wrote:
> So I have tryed to transform my PC-linux in an
> TapeRecorderPlayer and
> today I have succeded, by re-writing the ohci_csr_rom
> located in the ohci1394.h file.

That is great. Right now I use the Linux 1394 subsystem mainly for controlling
a digital VCR. A virtual VCR on another Linux host would provide the perfect
debugging tool for testing all those optional features that real VCRs do not
implement yet.

If you have some more specific questions, feel free to ask. You can also send
me your source if you like.

I would also like to see this thing run on an unmodofied Linux kernel. We
would need an interface for changing the CSR ROM at run time, oder maybe the
driver module should read the CSR rom from a file. The filename could be
specified at module loading time as an optional parameter. What do the driver
maintainers think of this idea?

   bye...
         Andreas Micklei

Receiving Video from other Computer

[<fra...@ya...>]

Since few days I started to work on isochronous
transfers. The main
difficultie is that I don't (and I can't) have a
camrecorder to
generate an isochronous flow. Moreover, the IEEE 1394
linux subsystem is not
able to generate one too. 

But I have a FireWire iMac and a PC-windoz, that are
able to
output isochronous packets IF they thought there is a
TapeRecorderPlayer connected to the bus.

So I have tryed to transform my PC-linux in an
TapeRecorderPlayer and
today I have succeded, by re-writing the ohci_csr_rom
located in the
ohci1394.h file.

Now, the Imac think that my Pc-linux is a TapeRecorder
and send it lots
of fcp commands and isochronous packets that I can
grab with dvgrab
(but can not see with libdv) or I can directly see the
movie with
xdv. But since I don't now exactly how an IEEE 1394
TapeRecorder has
to react, I just ask if someone is interrested by such
work or has any
experience with the AVC protocol for
TapeRecorderPlayer.

I still have a problem concerning video decoding with
xdv.
I have attach a sample from the output gave by xdv
(does anyone see the dog ?).

My goal is to build a TapeRecorder emulator on the top
of the IEEE
1394 linux subsystem and one day (when isochronous
output will work) a
tape player.

---

Franck Bonin


___________________________________________________________
Do You Yahoo!?
Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr

Re: ethernet driver(bug report)

[<fra...@ya...>]

I may have found when exactly this bug append.

Just try this :

1) insmod all the ieee 1394 modules (ieee1394, raw1394
& ohci1394)

2) delmod all the 3 modules.

3) generate a bus reset (by unplugging 1394 cables or
insmoding ieee 1394 modules on another node)

4) re-insmod all the 3 modules...

5) CRASH!

This bug is repetable as well with my ADS PYRO cards.

---

Franck Bonin

<Seb...@sy...> a écrit : >
>>>>> "Franck" == =?iso-8859-1?q?Franck=20Bonin?= 
> <iso-8859-1> writes:
> 
> Franck> Bug reporting with eth1394.c and ieee 1394
> subsystem My
> Franck> Hardware/software
> 
> Franck> 1) "Insmoding" 2 times the ohci module can
> crash one or the other
> Franck> PC...  to avoid this problem I have to
> restart my computer if I want
> Franck> te re-insmod the ohci module.
> 
> That's strange. Does it happen also if the pc is not
> connected on the
> bus ? Do you remove all the 1394 modules before
> insmoding ? I don't
> have a Pyro card here... anybody having the same
> problem ?


___________________________________________________________
Do You Yahoo!?
Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr

Re: ethernet driver(bug report)

[<fra...@ya...>]

I may have found when exactly this bug append.

Just try this :

1) insmod all the ieee 1394 modules (ieee1394, raw1394
& ohci1394)

2) delmod all the 3 modules.

3) generate a bus reset (by unplugging 1394 cables or
insmoding ieee 1394 modules on another node)

4) re-insmod all the 3 modules...

5) CRASH!

This bug is repetable as well with my ADS PYRO cards.

---

Franck Bonin

<Seb...@sy...> a écrit : >
>>>>> "Franck" == =?iso-8859-1?q?Franck=20Bonin?= 
> <iso-8859-1> writes:
> 
> Franck> Bug reporting with eth1394.c and ieee 1394
> subsystem My
> Franck> Hardware/software
> 
> Franck> 1) "Insmoding" 2 times the ohci module can
> crash one or the other
> Franck> PC...  to avoid this problem I have to
> restart my computer if I want
> Franck> te re-insmod the ohci module.
> 
> That's strange. Does it happen also if the pc is not
> connected on the
> bus ? Do you remove all the 1394 modules before
> insmoding ? I don't
> have a Pyro card here... anybody having the same
> problem ?


___________________________________________________________
Do You Yahoo!?
Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr

RE: ethernet driver(bug report)

[Mark K. <mk...@co...>]

I have some Pyro cards here, both LV22 and LV 23 based. 

I have not built the kernel in awhile, so I need to do that, but if someone
can give me the EXACT instructions for insmod'ing I will be happy to try it
out. (I do mean exact! I'm a hardware guy! Take pity!)

Let me know.
Mark

-----Original Message-----
From: Sebastien Rougeaux [mailto:Seb...@sy...]
Sent: Wednesday, May 10, 2000 9:18 PM
To: fra...@ya...
Cc: lin...@li...
Subject: Re: ethernet driver(bug report)


>>>>> "Franck" == =?iso-8859-1?q?Franck=20Bonin?=  <iso-8859-1> writes:

Franck> Bug reporting with eth1394.c and ieee 1394 subsystem My
Franck> Hardware/software

Franck> 1) "Insmoding" 2 times the ohci module can crash one or the other
Franck> PC...  to avoid this problem I have to restart my computer if I want
Franck> te re-insmod the ohci module.

That's strange. Does it happen also if the pc is not connected on the
bus ? Do you remove all the 1394 modules before insmoding ? I don't
have a Pyro card here... anybody having the same problem ?

Franck> 2) When I am using the ethernet driver with Pyro cards, I can
Franck> succesfully ping others computers (flood ping works without any
packet
Franck> loss). Telnet is working fine, I can also start small X application
Franck> like xcalc, xeyes or xclock. But, for exemple, if I was able to
start
Franck> bigger X applications with Adaptec HotConnect 8920 boards like
Franck> Netscape or Xsoldier, It is no more possible with Pyro cards.

So it is load related ?

Franck> Few time after application start, one board stop receiving packets
Franck> from the other board, as they still seem to be sent (by the other
Franck> board), according to kernel messages output. Moreover, the failling
Franck> card still can send packets.

One thing I have noticed but haven't fixed yet is that the bottom halves
in the irq handler are sometimes queued but not executed. You can try
to call them directly (instead of queueing) and see if it helps.

-- 
Sebastien Rougeaux
RSISE, The Australian National University

_______________________________________________
mailing list lin...@li...
http://lists.sourceforge.net/mailman/listinfo/linux1394-devel

RE: Libraw1394 question

[Mark K. <mk...@co...>]

Sebastien,
   Without waiting for the ACK, or without waiting for the response packet?
Mark

-----Original Message-----
From: Sebastien Rougeaux [mailto:Seb...@sy...]
Sent: Wednesday, May 10, 2000 7:19 PM
To: dai...@el...
Cc: ana...@ut...; lin...@li...
Subject: Re: Libraw1394 question


>>>>> "Olivier" == Olivier Daigle <dai...@el...> writes:

Olivier> --------------80790F6F4A9A7A46D27C5FE8 Content-Type: text/plain;
Olivier> charset=us-ascii Content-Transfer-Encoding: 7bit

Olivier> Hi Ashok, I managed to exchange raw data between 2 computers by
using
Olivier> an FCP-like method and libraw1394. Mainly, I copied FCP code and
Olivier> extended it to allow data being transferred by chunks of 2k
(instead
Olivier> of 512 bytes with bare FCP code).  This was pretty easy. Problem
is:
Olivier> there is a long delay between every data transfer and even with
fast
Olivier> machines (Pentium III 450MHz) and I can't manage to get data
Olivier> transferred faster than 2.5 Mbytes/sec. By using Frank Bonin's
Olivier> implementation of IP-over-1394 (which use async transactions), I
can
Olivier> ftp-transfer as fast as 15Mbytes/sec with slow machines (pentium
Olivier> 200MMX) so I guess I should be able to do as fast as him...

Olivier> I'm working on a way to speed-up transfer because I need at least
Olivier> 12Mbytes/sec.  I think the problem is that the code waits for an
Olivier> acknowledge before sending another packet. If you have any other
Olivier> suggestions, please help.

The OHCI driver has been designed to send multiple packets without waiting 
for the ack (currently the max is set to 32)... However I think it never
happens because of the internal mechanism of the subsystem/libraw. You
probably should ask Andreas Bombe about that.

-- 
Sebastien Rougeaux
RSISE, The Australian National University

_______________________________________________
mailing list lin...@li...
http://lists.sourceforge.net/mailman/listinfo/linux1394-devel

Re: I need some info on driver development status

[Sebastien R. <Seb...@sy...>]

>> Something wrong is happening during the bus reset phase, but there is not
>> much I can do without the proper hardware to figure it out...  I am
>> starting to suspect that irqs are not detected properly... is the irq
>> shared with other devices ?

Daniel> Indeed it is shared, and it has worried me before. It looks like Sony
Daniel> saved a few lines and routes every PCI device to IRQ 9. Both CardBus
Daniel> controllers are actually active. The rest of the stuff shouldn't
Daniel> generate any interrupts.

Could you please add a debug message at the top of the irq handler,
and verify that the irq handler is called when the driver is loaded.
Something like this:

		/* read the interrupt event register */
		event=reg_read(ohci, OHCI1394_IntEventSet);

		PRINT(KERN_INFO, ohci->id, "IntEvent: %08x",event);

You should have something like this after `insmod ohci1394`

........
ohci1394_0: resetting bus on request and attempting to become root
ieee1394: detected 1 ohci1394 adapter 
ohci1394_0: IntEvent: 00020010
ohci1394_0: IntEvent: 00020000
ohci1394_0: IntEvent: 00020000
.......

Daniel> Sebastien, below is a patch against the current ohci driver from CVS
Daniel> which you might want to consider. It does

Daniel> * process only those events in the IRQ handler that we haven't masked.
Daniel> * shut up interrupts from the card before freeing the IRQ.  * not go
Daniel> through all ifs in the IRQ handler when there are no events to
Daniel> process.

Thanks, I will have a look at it.

-- 
Sebastien Rougeaux
RSISE, The Australian National University

Re: I need some info on driver development status

[Daniel K. <dan...@st...>]

On Thu, 11 May 2000, Sebastien Rougeaux wrote:

[No-go Sony CXD3222 w/ current OHCI driver]
> Something wrong is happening during the bus reset phase, but there is
> not much I can do without the proper hardware to figure it out...
> I am starting to suspect that irqs are not detected properly... is the
> irq shared with other devices ? 

Indeed it is shared, and it has worried me before. It looks like Sony
saved a few lines and routes every PCI device to IRQ 9. Both CardBus
controllers are actually active. The rest of the stuff shouldn't generate
any interrupts.

> Another stuff to look at is the 
> content of the phy registers (you might have to uncomment some
> code and add a few debug lines in the driver source for that), and see
> if there is something wrong (using the 1394 specs). 

I had only access to the OHCI specs so far but 1394 is on its way. I'll
try to get my hands on the PHYs then.

> Look also back
> in the mailing list. Someone suggested to loop in the irq_handler until
> the node id become valid... but I haven't done anything about that yet.

Okay, I'll give it a try as well. Btw. is anyone else still seeing the
no-nodes-on-bus problem with the CXD3222 chipset (that's Sony's
OHCI-compliant chipset in latest Vaios)?

Sebastien, below is a patch against the current ohci driver from CVS which
you might want to consider. It does

* process only those events in the IRQ handler that we haven't masked. 
* shut up interrupts from the card before freeing the IRQ.
* not go through all ifs in the IRQ handler when there are no events to
  process.

I think they are correct, however testing is a bit tough when the driver
refuses to find any nodes on the bus. Well, my changes certainly didn't
make things worse for me. ;)

Regards,

Daniel.

Index: ohci1394.c
===================================================================
RCS file: /cvsroot/linux1394/ieee1394/ohci1394.c,v
retrieving revision 1.26
diff -u -r1.26 ohci1394.c
--- ohci1394.c	2000/04/25 09:46:32	1.26
+++ ohci1394.c	2000/05/11 09:31:44
@@ -1538,7 +1538,9 @@
 
 	do {
 		/* read the interrupt event register */
-		event=reg_read(ohci, OHCI1394_IntEventSet);
+		event=reg_read(ohci, OHCI1394_IntEventClear);
+		if (!event)
+			return;
 
 		/* clear the interrupt event register */
 		reg_write(ohci, OHCI1394_IntEventClear, event);
@@ -1700,11 +1702,9 @@
 				   "sequence");
 #endif
 		}
-		timeout--;
-	} while (event && timeout);
+	} while (--timeout);
 
-	if (event) PRINT(KERN_ERR, ohci->id, 
-			 "irq_handler timeout event=0x%08x", event);
+	PRINT(KERN_ERR, ohci->id, "irq_handler timeout event=0x%08x", event);
 }
 
 /* Put the buffer back into the dma context */
@@ -2571,6 +2571,9 @@
 			free_dma_fbuf_ctx(&ohci->fbuf_context[i]);
 		}
 #endif
+
+	/* Shut up card */
+	reg_write(ohci, OHCI1394_IntMaskClear, OHCI1394_masterIntEnable);
 
 	/* Free self-id buffer */
 	if (ohci->self_id_buffer)

-- 
	GNU/Linux Audio Mechanics - http://www.glame.de
	      GPG Key ID 89BF7E2B - http://www.keyserver.net

Bus resets

[<And...@no...>]

Hi,

I am writing a program for handling changes on the bus after bus resets,
i.e. detecting type of nodes (SBP2, AVC, ...) and building a topology tree.
I use a DV camera (Sony DCRPC7E) and two SBP2 hard drives from VST and have
come up with some strange behaviour when connecting/disconnecting these
devices. The problems are consistant, i.e. I am able to repeate them, but it
is difficult to say why they occur.

This is my setup:

* 1394 subsystem checked out from CVS yesterday
* Kernel version 2.2.14
* Red Hat 6.1
* P166 PC with TI OHCI adapter card

I use the following small test program:

----------------------------------------------------------------------------
-----
#include <stdio.h>
#include <libraw1394/raw1394.h>

int i = 0;

void reset_handler( raw1394handle_t handle )
{
   printf("\nBus reset #%d detected!\n", i);
   i++;
}

int main( void )
{
  raw1394handle_t handle;

  handle = raw1394_get_handle();
  raw1394_set_port(handle, 0);
  raw1394_set_bus_reset_handler( handle, (bus_reset_handler_t) reset_handler
);

  while(1)
    raw1394_loop_iterate(handle);

  return 0;
}
----------------------------------------------------------------------------
--------

I also do a 'cat /proc/kmsg' to get the debugging information from the ohci
and ieee modules.

Please see my observations below. It is possible that the problems are
hardware related, e.g. slow PC, inconsistant PHY and/or LINK chips etc but
it would be interesting to see if someone else has encountered the same
problems with other type of setups. In that case, it could be software
related bugs.


#1. A device is disconnected
Sometimes reset_handler() is called but I do not get any debugging
information from /proc/kmsg.

#2. One SBP2 drive already connected to PC, DV camera is connected
reset_handler() is called twice but /proc/kmsg only indicates one bus reset:

<6>ohci1394_0: Bus reset
<6>ohci1394_0: PhyControl: 000001FF
<6>ohci1394_0: SelfID process finished (phyid 4, not root)
<6>ohci1394_0: selfid packet 0x806c8094 rcvd
<7>ieee1394: including selfid 0x94806c80
<6>ohci1394_0: selfid packet 0x812c849c rcvd
<7>ieee1394: including selfid 0x9c842c81
<6>ohci1394_0: selfid packet 0x826c8094 rcvd
<7>ieee1394: including selfid 0x94806c82
<6>ohci1394_0: selfid packet 0x832c84ec rcvd
<7>ieee1394: including selfid 0xec842c83
<6>ohci1394_0: selfid packet 0x846c84b4 rcvd
<7>ieee1394: including selfid 0xb4846c84
<6>ohci1394_0: This node self-id is 0x846c84b4
<6>ohci1394_0: selfid packet 0x856c08c2 rcvd
<7>ieee1394: including selfid 0xc2086c85
<6>ohci1394_0: calling self-id complete
<6>ohci1394_0: Got phy packet ctx=0 ... discarded 

#3. A device is connected to the PC, no other devices are connected
No bus reset is generated at all.

#4. DV camera already connected to PC, SBP2 drive is connected or
disconnected
reset_handler() is not called and /proc/kmsg says:

<3>ohci1394_0: SelfID process finished but NodeID not valid: 0800FFC0
<6>ohci1394_0: PhyControl: 000001FF
<6>ohci1394_0: Got phy packet ctx=0 ... discarded
<6>ohci1394_0: Got phy packet ctx=0 ... discarded

 


_____________________________________________________________________
Anders Weitman, M.Sc             Phone    : +46 (0)13 4611341
Development Engineer             Fax      : +46 (0)13 4611001
Nokia Home Communications        Mobile   : +46 (0)70 2141319
Diskettgatan 11                  E-mail   : and...@no...
SE-583 35 Linkoping, Sweden      Internet : www.nokia.com/multimedia/

Re: updated dma to user space API

[Sebastien R. <Seb...@sy...>]

>>>>> "Anders" == Anders Weitman <And...@no...> writes:

>> Manfred Weihs wrote: I do not aggree with you. That should not be done by
>> the driver; any interpretation of the content of an iso packet should be
>> done by the application. The driver shall deliver the raw packets (as
>> libraw does now) and the application should decide, what the data is and
>> whether it has to look for sync tags and things like that.

Anders> I also think that interpretations of iso packets should be left to the
Anders> application. The 1394 driver should only address 1394 related issues,
Anders> not application specific stuff such as reception of isochronous DV
Anders> streams. DV is the most important usage for isochronous transfers
Anders> today but we will most likely see a lot of new things in the
Anders> future. The best thing to do, I think, is to keep the driver as clean
Anders> as possible and conentrate on having it up to date with the
Anders> development of 1394.

What I had in mind is a frame grabber driver... of course we can think of
a more low-level iso receive driver (in fact just removing the sync 
tag in my current iso receive driver would probably work for more general iso
reception).

-- 
Sebastien Rougeaux
RSISE, The Australian National University

Re: Memory requirements

[Sebastien R. <Seb...@sy...>]

>>>>> "Anders" == Anders Weitman <And...@no...> writes:

Anders> Hi, Do you know the amount of memory that the Linux 1394 subsystem
Anders> will require?  Right now the three modules (ieee1394, ohci1394 and
Anders> raw1394) use about 30k (according to lsmod). More important is perhaps
Anders> how much memory is allocated for variables, structs, buffers
Anders> etc. during operation? I guess this is depending on the number of
Anders> nodes so it should probable be specified in terms of x bytes/node.

IIRC, there is no dynamic memory allocation for the ohci driver during
operation (except of course the new iso recv functionality that I have
added recently which uses the /dev/ohci1394 device to allocate big
chunks of memory for video acquisition).

-- 
Sebastien Rougeaux
RSISE, The Australian National University

Re: I need some info on driver development status

[Sebastien R. <Seb...@sy...>]

Daniel> At our institute we have a CXD3222 in our Vaio and I'm the unfortunate
Daniel> person who has to get it running on Linux. I know you don't have
Daniel> access to this particular chipset yourself but perhaps you can provide
Daniel> me with a few hints on where to start hunting for problems. I'm using
Daniel> the latest IEEE1394 from CVS on a 2.3.99-pre6-pre3-ac1 (hey, this
Daniel> one's a must, isn't it? ;-), which has your mdelay() workaround for
Daniel> the self-id problems added. The Vaio is linked to a Sony TRV900E
Daniel> camcorder. Unfortunately for me the problem persists: I can
Daniel> rmmod/insmod/reboot like crazy, but I won't receive a single
Daniel> selfid. The only thing that looks unusual to me is an occasional

Something wrong is happening during the bus reset phase, but there is
not much I can do without the proper hardware to figure it out...
I am starting to suspect that irqs are not detected properly... is the
irq shared with other devices ? Another stuff to look at is the 
content of the phy registers (you might have to uncomment some
code and add a few debug lines in the driver source for that), and see
if there is something wrong (using the 1394 specs). Look also back
in the mailing list. Someone suggested to loop in the irq_handler until
the node id become valid... but I haven't done anything about that yet.

Sorry I can't help much more for the moment.

-- 
Sebastien Rougeaux
RSISE, The Australian National University

Re: ethernet driver(bug report)

[Sebastien R. <Seb...@sy...>]

>>>>> "Franck" == =?iso-8859-1?q?Franck=20Bonin?=  <iso-8859-1> writes:

Franck> Bug reporting with eth1394.c and ieee 1394 subsystem My
Franck> Hardware/software

Franck> 1) "Insmoding" 2 times the ohci module can crash one or the other
Franck> PC...  to avoid this problem I have to restart my computer if I want
Franck> te re-insmod the ohci module.

That's strange. Does it happen also if the pc is not connected on the
bus ? Do you remove all the 1394 modules before insmoding ? I don't
have a Pyro card here... anybody having the same problem ?

Franck> 2) When I am using the ethernet driver with Pyro cards, I can
Franck> succesfully ping others computers (flood ping works without any packet
Franck> loss). Telnet is working fine, I can also start small X application
Franck> like xcalc, xeyes or xclock. But, for exemple, if I was able to start
Franck> bigger X applications with Adaptec HotConnect 8920 boards like
Franck> Netscape or Xsoldier, It is no more possible with Pyro cards.

So it is load related ?

Franck> Few time after application start, one board stop receiving packets
Franck> from the other board, as they still seem to be sent (by the other
Franck> board), according to kernel messages output. Moreover, the failling
Franck> card still can send packets.

One thing I have noticed but haven't fixed yet is that the bottom halves
in the irq handler are sometimes queued but not executed. You can try
to call them directly (instead of queueing) and see if it helps.

-- 
Sebastien Rougeaux
RSISE, The Australian National University

Re: Libraw1394 question

[Sebastien R. <Seb...@sy...>]

>>>>> "Olivier" == Olivier Daigle <dai...@el...> writes:

Olivier> --------------80790F6F4A9A7A46D27C5FE8 Content-Type: text/plain;
Olivier> charset=us-ascii Content-Transfer-Encoding: 7bit

Olivier> Hi Ashok, I managed to exchange raw data between 2 computers by using
Olivier> an FCP-like method and libraw1394. Mainly, I copied FCP code and
Olivier> extended it to allow data being transferred by chunks of 2k (instead
Olivier> of 512 bytes with bare FCP code).  This was pretty easy. Problem is:
Olivier> there is a long delay between every data transfer and even with fast
Olivier> machines (Pentium III 450MHz) and I can't manage to get data
Olivier> transferred faster than 2.5 Mbytes/sec. By using Frank Bonin's
Olivier> implementation of IP-over-1394 (which use async transactions), I can
Olivier> ftp-transfer as fast as 15Mbytes/sec with slow machines (pentium
Olivier> 200MMX) so I guess I should be able to do as fast as him...

Olivier> I'm working on a way to speed-up transfer because I need at least
Olivier> 12Mbytes/sec.  I think the problem is that the code waits for an
Olivier> acknowledge before sending another packet. If you have any other
Olivier> suggestions, please help.

The OHCI driver has been designed to send multiple packets without waiting 
for the ack (currently the max is set to 32)... However I think it never
happens because of the internal mechanism of the subsystem/libraw. You
probably should ask Andreas Bombe about that.

-- 
Sebastien Rougeaux
RSISE, The Australian National University

Multiple computers.

[<fir...@se...>]

We are trying to connect multiple computers using firewire for a high
speed network, and are having a some problems with the driver.

When I load the driver on the first machine it can see all of the machines
on the network.  I used 'testlibraw' to check.  Now when I load the
drivers on the next machine 'testlibraw' reports that it is the only
machine on the network, but 'testlibraw' on the first machine now shows
comm between the two.  Then when I try to load the drivers on the next
machine, it has the same problem as the second machine, but now the second
machine can see all of the nodes on the network.  The keeps happening as I
load the drivers on other machines.

So is there a way to get the last machine to see all the computers on the
firewire network?

I am attaching the testlibraw output I got.

Our Machines

kernel			2.2.15
Firewire driver		CVS May 10 2000
libraw			0.6
Proccessor		dual PII 350
RAM			256Meg
Firewire card		Unibrain FireBoard 400
Ethernet		3 DEC DC21140 (tulip)
Video			GeForce

Judd Tracy
jt...@is...

RE: updated dma to user space API

[<And...@no...>]

> > Sebastien Rougeaux wrote:
> > The important part for me
> > is that the driver:
> > 
> >     . allows multi-buffering (tunable)
> >     . doesn't waste CPU time
> >     . does frame synchronization

> Manfred Weihs wrote:
> I do not aggree with you. That should not be done by the driver; any
> interpretation of the content of an iso packet should be done by the
> application. The driver shall deliver the raw packets (as libraw does
> now) and the application should decide, what the data is and 
> whether it has to look for sync tags and things like that.

I also think that interpretations of iso packets should be left to the
application. The 1394 driver should only address 1394 related issues, not
application specific stuff such as reception of isochronous DV streams. DV
is the most important usage for isochronous transfers today but we will most
likely see a lot of new things in the future. The best thing to do, I think,
is to keep the driver as clean as possible and conentrate on having it up to
date with the development of 1394.


Keep up the good work everyone!


Regards,
Anders Weitman

RE: Libraw1394 question

[Mark K. <mk...@co...>]

Oliver,
   I'm not clear that the acknowledge packet is the issue because it is
hardware generated and returns quite quickly. Generally this doesn't take
much extra time, although on an un-optimized bus with the gap count set to
63 it is measurable.
 
   We've done some similar work under WinDoze - I don't know how closely it
tracks here, but in that environment we were seeing interrupt latencies
driving the return of response packets in the order of 1mS, implying the
ability to do about only about 1000 I/O's per second between 2 moderately
fast PCs. (333/425MHz)
 
   Assuming you're seeing something similar under Linux, then I'd expect
that you'd get a throughput of about 1000 packets/second * 2K bytes/packet *
8 bits/byte = 16Mb/S, or 2MB/S, roughly similar to the sorts of numbers you
seem to be seeing.
 
   You could check that this is driven mostly by system latencies by
changing you packet sizes to say 1K and 512 bytes and see if the throughput
changes roughly linearly.
 
   What's the solution? The applications that are driving this pipe need to
be able to make multiple requests of the 1394 bus such that the overall
system latency gets covered up and data is moving all the time. When you do
that you start to see the performance go up significantly. Certainly you'll
need a driver stack that supports this cleanly.
 
   This sort of issue isn't likely to rear it's ugly head for those
applications transferring real-time video data from consumer level
camcorders. It is, however, likely to be a big problem for high performance
disk drives talking SPB-2.
 
With best regards,
Mark

-----Original Message-----
From: Olivier Daigle [mailto:dai...@el...]
Sent: Tuesday, May 09, 2000 1:33 PM
To: Ashok Natarajan
Cc: Linux1394-devel
Subject: Re: Libraw1394 question


Hi Ashok, 
  I managed to exchange raw data between 2 computers by using an FCP-like
method and libraw1394. Mainly, I copied FCP code and extended it to allow
data being transferred by chunks of 2k (instead of 512 bytes with bare FCP
code). This was pretty easy. Problem is: there is a long delay between every
data transfer and even with fast machines (Pentium III 450MHz) and I can't
manage to get data transferred faster than 2.5 Mbytes/sec. By using Frank
Bonin's implementation of IP-over-1394 (which use async transactions), I can
ftp-transfer as fast as 15Mbytes/sec with slow machines (pentium 200MMX) so
I guess I should be able to do as fast as him... 

I'm working on a way to speed-up transfer because I need at least
12Mbytes/sec. I think the problem is that the code waits for an acknowledge
before sending another packet. If you have any other suggestions, please
help. 


  Olivier 


Ashok Natarajan wrote: 


Hi Olivier, 
   I was also trying to implement the asynchronous data transfer between 
linux pc's through the 1394 interface.Then i got busy in something else 
and didnt have time to work on this.From the postings i came to know that 
u r trying to develop and application to perform the asynchronous 
tarnasactions.I'll be willing to assist u in testing of u'r code.Do u have 
any code written at all?. 

Ashok. 
  


    _______________________________________________________________________ 
   /    Ashok Natarajan        |                   |                       \

   |   Research Assistant      |     __  __        |                       |

   |     Dept. of ECE          |    /  \/  \       |  Some goals are so    |

   |   Univ. of Tennessee      |    |      |       |  worthy,its glorious  |

   |___________________________|     \    /        |  even to fail.        |

   | Ph.no:                    |       \/          |                       |

   |   (931)-393-7107 (home)   |                   |                       |

   |   (931)-393-7366 (work)   | ana...@ut... |                       |

   ___________________________|___________________|_______________________/

--

Olivier Daigle

Projet Harfang

(514) 396-8800 ext.7699
  

Re: Libraw1394 question

[Olivier D. <dai...@el...>]

Hi Ashok,
  I managed to exchange raw data between 2 computers by using an FCP-like
method and libraw1394. Mainly, I copied FCP code and extended it to allow data
being transferred by chunks of 2k (instead of 512 bytes with bare FCP code).
This was pretty easy. Problem is: there is a long delay between every data
transfer and even with fast machines (Pentium III 450MHz) and I can't manage to
get data transferred faster than 2.5 Mbytes/sec. By using Frank Bonin's
implementation of IP-over-1394 (which use async transactions), I can
ftp-transfer as fast as 15Mbytes/sec with slow machines (pentium 200MMX) so I
guess I should be able to do as fast as him...

I'm working on a way to speed-up transfer because I need at least 12Mbytes/sec.
I think the problem is that the code waits for an acknowledge before sending
another packet. If you have any other suggestions, please help.

  Olivier

Ashok Natarajan wrote:

> Hi Olivier,
>    I was also trying to implement the asynchronous data transfer between
> linux pc's through the 1394 interface.Then i got busy in something else
> and didnt have time to work on this.From the postings i came to know that
> u r trying to develop and application to perform the asynchronous
> tarnasactions.I'll be willing to assist u in testing of u'r code.Do u have
> any code written at all?.
>
> Ashok.
>
>
>     _______________________________________________________________________
>    /    Ashok Natarajan        |                   |                       \
>    |   Research Assistant      |     __  __        |                       |
>    |     Dept. of ECE          |    /  \/  \       |  Some goals are so    |
>    |   Univ. of Tennessee      |    |      |       |  worthy,its glorious  |
>    |___________________________|     \    /        |  even to fail.        |
>    | Ph.no:                    |       \/          |                       |
>    |   (931)-393-7107 (home)   |                   |                       |
>    |   (931)-393-7366 (work)   | ana...@ut... |                       |
>    ___________________________|___________________|_______________________/

--
Olivier Daigle
Projet Harfang
(514) 396-8800 ext.7699