linux1394-devel Mailing List for IEEE 1394 for Linux (Page 529)
Brought to you by:
aeb,
bencollins
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
(39) |
Apr
(154) |
May
(172) |
Jun
(237) |
Jul
(127) |
Aug
(135) |
Sep
(193) |
Oct
(175) |
Nov
(173) |
Dec
(148) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(161) |
Feb
(225) |
Mar
(193) |
Apr
(158) |
May
(179) |
Jun
(292) |
Jul
(146) |
Aug
(134) |
Sep
(185) |
Oct
(190) |
Nov
(149) |
Dec
(161) |
2002 |
Jan
(186) |
Feb
(236) |
Mar
(254) |
Apr
(207) |
May
(189) |
Jun
(182) |
Jul
(202) |
Aug
(155) |
Sep
(149) |
Oct
(449) |
Nov
(191) |
Dec
(108) |
2003 |
Jan
(174) |
Feb
(242) |
Mar
(243) |
Apr
(255) |
May
(202) |
Jun
(290) |
Jul
(237) |
Aug
(178) |
Sep
(101) |
Oct
(153) |
Nov
(144) |
Dec
(95) |
2004 |
Jan
(162) |
Feb
(278) |
Mar
(282) |
Apr
(152) |
May
(127) |
Jun
(138) |
Jul
(94) |
Aug
(63) |
Sep
(64) |
Oct
(150) |
Nov
(102) |
Dec
(197) |
2005 |
Jan
(102) |
Feb
(172) |
Mar
(89) |
Apr
(158) |
May
(139) |
Jun
(160) |
Jul
(288) |
Aug
(89) |
Sep
(201) |
Oct
(92) |
Nov
(190) |
Dec
(139) |
2006 |
Jan
(121) |
Feb
(204) |
Mar
(133) |
Apr
(134) |
May
(91) |
Jun
(226) |
Jul
(122) |
Aug
(101) |
Sep
(144) |
Oct
(141) |
Nov
|
Dec
|
2023 |
Jan
(19) |
Feb
(1) |
Mar
(5) |
Apr
(5) |
May
(33) |
Jun
(17) |
Jul
|
Aug
|
Sep
(3) |
Oct
(1) |
Nov
(5) |
Dec
(40) |
2024 |
Jan
(26) |
Feb
(14) |
Mar
(26) |
Apr
(46) |
May
(17) |
Jun
(47) |
Jul
(23) |
Aug
(72) |
Sep
(34) |
Oct
|
Nov
|
Dec
|
From: Ben C. <bco...@de...> - 2000-05-27 00:13:22
|
I'm messing around with getting the ieee1394 drivers working across platforms (specifically I am testing with sparc64). The unusual thing about sparc64 is that the user space is (currently) 32bit, while the kernel is 64bit. This makes sizeof(struct raw1394_request) different between the kernel driver and the libraw1394 library (56 in the driver, 40 in the library, mainly because unsigned int and size_t are 8 in the kernel and 4 in userspace). Now, usually this would be overcome in cases like this for sparc64 because the comunication is via ioctl's, and sparc64 has conversions. However, this is a different case since we are reading and writing directly to the device. I forced the size's in the library to match that of driver for each member of the struct, but that causes an oops with: Unsupported unaligned load/store trap for kernel testlibraw(13217): Kernel does fpu/atomic unaligned load/store. Any ideas on working around this? I suspect that libraw1394 will have to be special cased for this (which is a hack) but the driver code still performs this unaligned bit on 64bit (which I suspect is the real problem). The driver most likely needs to use things like u32 for the struct, and libraw1394 will need some configure.in macros for detecting properly sized replacements to match the kernel. I am going to start looking at it, but I wanted some other people closer to the code to realize this (mostly because there are probably other 64bit issues in the drivers aswell). Thanks, Ben -- -----------=======-=-======-=========-----------=====------------=-=------ / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` bco...@de... -- bco...@op... -- bco...@li... ' `---=========------=======-------------=-=-----=-===-======-------=--=---' |
From: Mark K. <mk...@co...> - 2000-05-26 20:25:04
|
Olivier, Thanks for pointing me in a good direction. I should have included the same sort of information. I'll do that now. I tried this with either my Sony drive or a second PC. Either way I get the same results. Assuming that I have 1 PC connected to the Sony drive (or a 2nd PC), and I pull the cable, this is what I see: May 26 13:05:49 bambi kernel: ohci1394_0: Got phy packet ctx=0 ... discarded May 26 13:07:20 bambi kernel: ohci1394_0: IntEvent: 04020010 May 26 13:07:20 bambi kernel: ohci1394_0: Got RQPkt interrupt status=0x00008409 May 26 13:07:20 bambi kernel: ohci1394_0: PhyControl: 000001FF May 26 13:07:20 bambi kernel: ohci1394_0: IntEvent: 00010000 May 26 13:07:20 bambi kernel: ohci1394_0: SelfID process finished (phyid 0, root) May 26 13:07:20 bambi kernel: ohci1394_0: selfid packet 0x807f8456 rcvd May 26 13:07:20 bambi kernel: ohci1394_0: This node self-id is 0x807f8456 May 26 13:07:20 bambi kernel: ohci1394_0: calling self-id complete May 26 13:07:20 bambi kernel: ohci1394_0: IntEvent: 00000000 May 26 13:07:20 bambi kernel: ohci1394_0: Got phy packet ctx=0 ... discarded So, in this case, the PC is alone, generates it's own Self-ID packet, and reports that to the upper layers and on to the application. Everything looks good. However, when I reassert the cable (to the drive or the 2nd PC) this is what I see: May 26 13:07:22 bambi kernel: ohci1394_0: IntEvent: 00030010 May 26 13:07:22 bambi kernel: ohci1394_0: Bus reset May 26 13:07:22 bambi kernel: ohci1394_0: Cancel request received May 26 13:07:22 bambi kernel: ohci1394_0: Got RQPkt interrupt status=0x00008409 May 26 13:07:22 bambi kernel: ohci1394_0: SelfID process finished but NodeID not valid: 0800FFC0 May 26 13:07:22 bambi kernel: ohci1394_0: IntEvent: 00020000 May 26 13:07:22 bambi last message repeated 27 times May 26 13:07:22 bambi kernel: ohci1394_0: IntEvent: 04020000 May 26 13:07:22 bambi kernel: ohci1394_0: PhyControl: 000001FF May 26 13:07:22 bambi kernel: ohci1394_0: IntEvent: 00020000 May 26 13:07:22 bambi kernel: ohci1394_0: IntEvent: 00000000 May 26 13:07:22 bambi kernel: ohci1394_0: Got phy packet ctx=0 ... discarded I see the same problem you do. The Self-ID process seems to die, but you are correct that the stack is at least seeing a bus reset. I expect that Andreas B. should be able to zero in on this pretty quickly. I'll poke around in the code also and see what I can figure out. (But that won't be quickly!!) Mark -----Original Message----- From: Olivier Daigle [mailto:dai...@el...] Sent: Friday, May 26, 2000 12:18 PM To: Mark Knecht Cc: Linux1394 Developer's Reflector (E-mail); Andreas Bombe (E-mail); Andreas Micklei (E-mail) Subject: Re: Bus Reset Observations I noticed EXACTLY the same problem. Here is my debug info: (I added the output of the Node Identification and status register (11'h0E8) May 26 15:05:50 milk kernel: ohci1394_0: Bus reset May 26 15:05:50 milk kernel: ohci1394_0: SelfID process finished but NodeID not valid: 0800FFC0 May 26 15:05:50 milk kernel: ohci1394_0: irq_handler timeout event=0x00020000 May 26 15:05:50 milk kernel: ohci1394_0: Got phy packet ctx=0 ... discarded The problem is that the device DOES recognize the cable insertion, but the SelfID process terminates with an invalid NodeID. (it should be something like 0x8800FFC0 instead of 0x0800FFC0). The MSB (bit 31) of the quadlet says if the 1394 OHCI has a valid node number. The 27nd bit is the CPS (Cable Power Status OK). I noticed that when there is 2 OHCI cards (in Linux boxes) on the bus, there is always one card that ends with an invalid NodeID and the other ends with a valid NodeID. My knowledge of the ohci driver (and ieee1394 in general) is not high enough to track down the problem by now. Olivier Mark Knecht wrote: Hi, I don't know whether to report this as a stack problem or a gscanbus problem. (I think stack...) I am seeing a very specific and repeatable problem. To me, at a high level, this looks like incorrect operation at the stack level. On my systems I believe that when the Linux based PC is not connected to any 1394 devices, and a cable to a 1394 device is inserted into the OHCI card, the 1394 stack does not recognize a cable insertion. Can someone verify whether they are seeing or not seeing the same results? Thanks, Mark TESTS...... I have set up 3 PCs with RH 6.2, downloaded the 2.2.15 kernel, built it first with the patch, and then with the CVS tree. I have downloaded and installed 1394libraw from the CVS tree and installed that. I have downloaded gscanbus and am running it on all three PCs. Messages in /var/log look pretty reasonable based on how many devices are on the bus. I can set up a network with the 3 PCs and a few other peripherals, and sometimes get gscanbus to correctly see the topology identically on all three machines. (And sometimes not!) For gscanbus I built a guid-resolv.conf file with the GUIDs of each PC and put the same file on all three PCs. ***** Test 1 ***** Connect 2 PCs and a Sony CD drive. Start gscanbus. Observations: I see 2 PCs and one unknown device. If I pull the cable on the drive, I see 2 PCs. (Bus Reset detected) If I insert the cable, the unknown device comes back. (Bus Reset Detected) If I power off the drive, the unknown device disappears. (Bus Reset Detected) If I power the drive back up, the unknown device reappears. (Bus Reset Detected) ***************** ***** Test 2 ***** Connect 1 PC and the Sony CD drive. Start gscanbus. Observations: I see 1 PC and one unknown device. If I pull the cable, I see 1 PC. (Bus reset detected) If I insert the drive cable, the drive does not come back. (Bus Reset is not detected) If I power off the drive, no change in the screen, because the screen is incorrect right now. (Bus Reset Detected) If I power the drive back up, then unknown device reappears. (Bus Reset Detected) _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel -- Olivier Daigle Projet Harfang (514) 396-8800 ext.7699 |
From: Olivier D. <dai...@el...> - 2000-05-26 19:23:34
|
I forgot to say... If the cable is connected to both computers and I load ieee1394 modules on the machines, the load of modules generates a "soft" reset on the bus and SelfID always complete successfully. Olivier Mark Knecht wrote: > Hi, > I don't know whether to report this as a stack problem or a gscanbus > problem. (I think stack...) I am seeing a very specific and repeatable > problem. To me, at a high level, this looks like incorrect operation at the > stack level. On my systems I believe that when the Linux based PC is not > connected to any 1394 devices, and a cable to a 1394 device is inserted into > the OHCI card, the 1394 stack does not recognize a cable insertion. > > Can someone verify whether they are seeing or not seeing the same > results? > > Thanks, > Mark > > > TESTS...... > > I have set up 3 PCs with RH 6.2, downloaded the 2.2.15 kernel, built it > first with the patch, and then with the CVS tree. I have downloaded and > installed 1394libraw from the CVS tree and installed that. I have downloaded > gscanbus and am running it on all three PCs. Messages in /var/log look > pretty reasonable based on how many devices are on the bus. I can set up a > network with the 3 PCs and a few other peripherals, and sometimes get > gscanbus to correctly see the topology identically on all three machines. > (And sometimes not!) > > For gscanbus I built a guid-resolv.conf file with the GUIDs of each PC > and put the same file on all three PCs. > > ***** Test 1 ***** > > Connect 2 PCs and a Sony CD drive. Start gscanbus. > > Observations: > I see 2 PCs and one unknown device. > If I pull the cable on the drive, I see 2 PCs. (Bus Reset detected) > If I insert the cable, the unknown device comes back. (Bus Reset Detected) > If I power off the drive, the unknown device disappears. (Bus Reset > Detected) > If I power the drive back up, the unknown device reappears. (Bus Reset > Detected) > > ***************** > > ***** Test 2 ***** > > Connect 1 PC and the Sony CD drive. Start gscanbus. > > Observations: > > I see 1 PC and one unknown device. > If I pull the cable, I see 1 PC. (Bus reset detected) > > If I insert the drive cable, the drive does not come back. (Bus Reset is not > detected) > > If I power off the drive, no change in the screen, because the screen is > incorrect right now. (Bus Reset Detected) > If I power the drive back up, then unknown device reappears. (Bus Reset > Detected) > > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux1394-devel -- Olivier Daigle Projet Harfang (514) 396-8800 ext.7699 |
From: Olivier D. <dai...@el...> - 2000-05-26 19:20:31
|
I noticed EXACTLY the same problem. Here is my debug info: (I added the output of the Node Identification and status register (11'h0E8) May 26 15:05:50 milk kernel: ohci1394_0: Bus reset May 26 15:05:50 milk kernel: ohci1394_0: SelfID process finished but NodeID not valid: 0800FFC0 May 26 15:05:50 milk kernel: ohci1394_0: irq_handler timeout event=0x00020000 May 26 15:05:50 milk kernel: ohci1394_0: Got phy packet ctx=0 ... discarded The problem is that the device DOES recognize the cable insertion, but the SelfID process terminates with an invalid NodeID. (it should be something like 0x8800FFC0 instead of 0x0800FFC0). The MSB (bit 31) of the quadlet says if the 1394 OHCI has a valid node number. The 27nd bit is the CPS (Cable Power Status OK). I noticed that when there is 2 OHCI cards (in Linux boxes) on the bus, there is always one card that ends with an invalid NodeID and the other ends with a valid NodeID. My knowledge of the ohci driver (and ieee1394 in general) is not high enough to track down the problem by now. Olivier Mark Knecht wrote: > Hi, > I don't know whether to report this as a stack problem or a gscanbus > problem. (I think stack...) I am seeing a very specific and repeatable > problem. To me, at a high level, this looks like incorrect operation at the > stack level. On my systems I believe that when the Linux based PC is not > connected to any 1394 devices, and a cable to a 1394 device is inserted into > the OHCI card, the 1394 stack does not recognize a cable insertion. > > Can someone verify whether they are seeing or not seeing the same > results? > > Thanks, > Mark > > > TESTS...... > > I have set up 3 PCs with RH 6.2, downloaded the 2.2.15 kernel, built it > first with the patch, and then with the CVS tree. I have downloaded and > installed 1394libraw from the CVS tree and installed that. I have downloaded > gscanbus and am running it on all three PCs. Messages in /var/log look > pretty reasonable based on how many devices are on the bus. I can set up a > network with the 3 PCs and a few other peripherals, and sometimes get > gscanbus to correctly see the topology identically on all three machines. > (And sometimes not!) > > For gscanbus I built a guid-resolv.conf file with the GUIDs of each PC > and put the same file on all three PCs. > > ***** Test 1 ***** > > Connect 2 PCs and a Sony CD drive. Start gscanbus. > > Observations: > I see 2 PCs and one unknown device. > If I pull the cable on the drive, I see 2 PCs. (Bus Reset detected) > If I insert the cable, the unknown device comes back. (Bus Reset Detected) > If I power off the drive, the unknown device disappears. (Bus Reset > Detected) > If I power the drive back up, the unknown device reappears. (Bus Reset > Detected) > > ***************** > > ***** Test 2 ***** > > Connect 1 PC and the Sony CD drive. Start gscanbus. > > Observations: > > I see 1 PC and one unknown device. > If I pull the cable, I see 1 PC. (Bus reset detected) > > If I insert the drive cable, the drive does not come back. (Bus Reset is not > detected) > > If I power off the drive, no change in the screen, because the screen is > incorrect right now. (Bus Reset Detected) > If I power the drive back up, then unknown device reappears. (Bus Reset > Detected) > > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux1394-devel -- Olivier Daigle Projet Harfang (514) 396-8800 ext.7699 |
From: Mark K. <mk...@co...> - 2000-05-26 18:12:58
|
Hi, I don't know whether to report this as a stack problem or a gscanbus problem. (I think stack...) I am seeing a very specific and repeatable problem. To me, at a high level, this looks like incorrect operation at the stack level. On my systems I believe that when the Linux based PC is not connected to any 1394 devices, and a cable to a 1394 device is inserted into the OHCI card, the 1394 stack does not recognize a cable insertion. Can someone verify whether they are seeing or not seeing the same results? Thanks, Mark TESTS...... I have set up 3 PCs with RH 6.2, downloaded the 2.2.15 kernel, built it first with the patch, and then with the CVS tree. I have downloaded and installed 1394libraw from the CVS tree and installed that. I have downloaded gscanbus and am running it on all three PCs. Messages in /var/log look pretty reasonable based on how many devices are on the bus. I can set up a network with the 3 PCs and a few other peripherals, and sometimes get gscanbus to correctly see the topology identically on all three machines. (And sometimes not!) For gscanbus I built a guid-resolv.conf file with the GUIDs of each PC and put the same file on all three PCs. ***** Test 1 ***** Connect 2 PCs and a Sony CD drive. Start gscanbus. Observations: I see 2 PCs and one unknown device. If I pull the cable on the drive, I see 2 PCs. (Bus Reset detected) If I insert the cable, the unknown device comes back. (Bus Reset Detected) If I power off the drive, the unknown device disappears. (Bus Reset Detected) If I power the drive back up, the unknown device reappears. (Bus Reset Detected) ***************** ***** Test 2 ***** Connect 1 PC and the Sony CD drive. Start gscanbus. Observations: I see 1 PC and one unknown device. If I pull the cable, I see 1 PC. (Bus reset detected) If I insert the drive cable, the drive does not come back. (Bus Reset is not detected) If I power off the drive, no change in the screen, because the screen is incorrect right now. (Bus Reset Detected) If I power the drive back up, then unknown device reappears. (Bus Reset Detected) |
From: <fir...@se...> - 2000-05-26 13:05:52
|
On Fri, 26 May 2000, [iso-8859-1] Franck Bonin wrote: > I have done some improvements with eth1394 driver and > ohci1394 > lowlevel driver. Now I can reach High speed data > transfer. > > For exemple, I can download large files such as > 20Mbytes > In 5 seconds, just look : That is good news. > I also would like to ask if someone know a way to > build an UNIQUE HW > address of 6 bytes, by using some kind of unique ID > obtained from IEEE > 1394 cards. > > This would be a better solution instead of using nodes > number. Could it be possible to set the ethernet address from a load-time parameter when you insmod the module. This would allow unique and constant addresses, but would be hard to map to the cards I guess. Judd Tracy jt...@is... |
From: <fra...@ya...> - 2000-05-26 07:16:04
|
I have done some improvements with eth1394 driver and ohci1394 lowlevel driver. Now I can reach High speed data transfer. For exemple, I can download large files such as 20Mbytes In 5 seconds, just look : ftp> mget j* mget jdk1_2_2-linux-i386.tar.gz? y 200 PORT command successful. 150 Opening BINARY mode data connection for jdk1_2_2-linux-i386.tar.gz (21580986 bytes). 226 Transfer complete. 21580986 bytes received in 5.23 secs (4e+03 Kbytes/sec) ftp> by The driver with its improvements still stay here : http://www.chez.com/kayle/IEEE_1394/ether_1394.tgz I also would like to ask if someone know a way to build an UNIQUE HW address of 6 bytes, by using some kind of unique ID obtained from IEEE 1394 cards. This would be a better solution instead of using nodes number. ----------- Franck Bonin ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr |
From: Andreas B. <and...@mu...> - 2000-05-25 21:26:46
|
On Wed, May 24, 2000 at 10:45:33AM -0400, Ale...@ne... wrote: > > I am writing a new piece of driver to go on top of OHCI. I generate messages > and send them by calling hpsb_write(). > > My questions are: > 1. The hpsb_write() function exists but no-one in the existing stack calls it. > Is there any reason for that? See 3. It just stayed around. > 2. Eventuallt hpsb_write() calls hpsb_send_packet() which hangs the kernel > before the two calls to down(), even though the semaphore is initialized. This > is my major concern now and I will be happy if you have an idea why this > happens. It wasn't tested for a long time. Could be that a bug crept in. > 3. Are there any restrictions on using hpsb_write()? Are there prerequisits one > has to fulfill before calling it? It sleeps waiting for packet completion, you therefore need a process context to use it. This is only given if you call hpsb_write() in a kernel function that was called from user space. It can not be used in interrupt context (most of the stack works there, since it has no separate kernel thread). You have to use the other functions like hpsb_make_*packet for more flexible use. What are you trying to do exactly? -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Arne S. <ar...@sc...> - 2000-05-25 21:22:25
|
Feel free to enter the links in my link list : http://www.schirmacher.de/cgi-bin/dclinks.cgi There is also a technical documentation section. Arne -----Original Message----- From: Daniel Kobras [SMTP:dan...@st...] Sent: Wednesday, May 24, 2000 2:56 PM To: linux1394-devel Subject: Re: What cable is needed? On Tue, 23 May 2000, Jurgen Kramer wrote: > Is it really that simple? I could image the firewire bus is just like a SCSI > bus only serial. I really have to find some more info on how it old works. > Any links? I found some of the old Intel docs and presentations to be quite informative, ftp://ftp.austin.ibm.com/pub/chrptech/1394ohci/, especially 1394ovw.PDF. More rather technical info on specific topics is on http://developer.intel.com/technology/1394/ and http://www.microsoft.com/hwdev/xpapers/pc98/08fire98.htm (Btw. the microsoft site has the only semi-sane CSR description I could get hold of. Short of the $100 IEC/ISO specs that is.) Andreas, maybe some of those links could be mentioned on the linux1394 homepage? Daniel. -- GNU/Linux Audio Mechanics - http://www.glame.de GPG Key ID 89BF7E2B - http://www.keyserver.net _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Jurgen K. <GTM...@in...> - 2000-05-25 16:39:06
|
Hi, I have bought two new PCI IEEE 1394 OHCI 1.0 complaint controllers which are not recognized by the current drivers (both CVS and kernel). The card is a Dynalink 1394P which uses a controller from Lucent Microelectronics. The vendor ID is also not recognized by the kernel so I lookup up the vendor ID at the PCI Special Interest Group but it's not there (yet?). So here are the numbers: Vendor ID: 0x11c1 Lucent Microelectronics Device ID: 0x5811 FW323 For more info: http://www.lucent.com/micro/1394/document.html FW323 Integrated OCHI Link and PHY http://www.lucent.com/micro/1394/docs/PN99156-02.pdf After modifing both ohci1394.h and ohci1394.c the cards worked so there is no problem there. Could you insert this device in your code? Thanks, Jurgen |
From: Arne S. <ar...@sc...> - 2000-05-24 18:18:38
|
Hi all, I have set up a new IEEE1394 and Digital Video related link list on http://www.schirmacher.de/cgi-bin/dclinks.cgi . Please check it out and add your own favorite links to it. Also if your own website is already mentioned there, please check the comments for accuracy. There is also a small discussion board on http://www.schirmacher.de/cgi-bin/dcboard.cgi which may be of interest too. According to the logfiles my website draws about 500 - 1000 hits per day with a clear increasing tendency. Maybe we can use it to promote the whole ieee1394 idea, but it is just too time-consuming for me to do it alone (I still have some new ideas to code...). Anybody wants to volunteer for things like FAQs, application stories, success stories etc.? Arne |
From: Mark K. <mk...@co...> - 2000-05-24 16:53:02
|
I've noticed that if my Linux box is logged out, waiting for someone to log in, and sits for a few hours, I am likely to see: ohci1394_0: phy reg received outside of bus resetsequence on the screen when I come back... Should this be happening? |
From: Mark K. <mk...@co...> - 2000-05-24 16:50:30
|
Arne, I have not started using dvgrab yet, but I am seeing similar things with gscanbus. Most of the time it works, but some times it does not. You might check you /var/log/messages file. When gscanbus is not working, I generally see a couple of things in there which cause the system and/or the app some concerns. (i.e. - gscanbus core dumping...) 1) A message about receiving an 'unsolicited response packet', such as: May 24 09:11:02 bambi kernel: ohci1394_0: Got reqTxComplete interrupt status=0x00008043 May 24 09:11:02 bambi kernel: ohci1394_0: Packet sent to node 2 ack=0x3 spd=2 ctx=0 May 24 09:11:02 bambi kernel: ohci1394_0: IntEvent: 00000000 May 24 09:11:02 bambi kernel: ohci1394_0: IntEvent: 00000020 May 24 09:11:02 bambi kernel: ohci1394_0: Got RSPkt interrupt status=0x00008411 May 24 09:11:02 bambi kernel: ohci1394_0: IntEvent: 00000000 May 24 09:11:02 bambi kernel: ohci1394_0: Packet received from node 0 ack=0x11 spd=0 tcode=0x6 length=20 data=0x20e42204 ctx=1 May 24 09:11:02 bambi kernel: ieee1394: unsolicited response packet received - np (This was the last line in my file when gscanbus core dumped this morning.) 2) A message about Self-ID process completing but the Node ID not being valid, such as: May 23 06:47:17 bambi kernel: ohci1394_0: IntEvent: 00000000 May 23 06:47:20 bambi kernel: ohci1394_0: IntEvent: 00030010 May 23 06:47:20 bambi kernel: ohci1394_0: Bus reset May 23 06:47:20 bambi kernel: ohci1394_0: AT dma reset ctx=0, aborting transmission May 23 06:47:20 bambi kernel: ohci1394_0: AT dma reset ctx=0, aborting transmission May 23 06:47:20 bambi kernel: ohci1394_0: Cancel request received May 23 06:47:20 bambi kernel: ohci1394_0: Got RQPkt interrupt status=0x00008409 May 23 06:47:20 bambi kernel: ohci1394_0: SelfID process finished but NodeID not valid: 0800FFC0 May 23 06:47:20 bambi kernel: ohci1394_0: IntEvent: 00020000 May 23 06:47:20 bambi last message repeated 42 times May 23 06:47:20 bambi kernel: ohci1394_0: IntEvent: 04020000 May 23 06:47:20 bambi kernel: ohci1394_0: PhyControl: 000001FF May 23 06:47:20 bambi kernel: ohci1394_0: IntEvent: 00020000 May 23 06:47:20 bambi kernel: ohci1394_0: IntEvent: 00000000 Both of these events seem to happen in and around the times gscanbus is failing, but I can't say for certain that they are a cause or effect. I'd be very interested to find out if your failures show any of these messages as it might point to the stack vs. the application. Still poking around, Mark -----Original Message----- From: Arne Schirmacher [mailto:ar...@sc...] Sent: Tuesday, May 23, 2000 10:36 PM To: 'Mark Knecht'; Linux1394 Developer's Reflector (E-mail) Subject: Another boot problem? I have noticed another boot problem, but I could not figure it out: Sometimes the ieee1394 subsystem won't work with dvgrab. I boot my system, do the insmod of all the required modules, and dvgrab won't receive any data. Then I do an rmmod followed by another insmod and usually it works now. This happens in about 20% of all boots. I have scripts for the insmod and rmmod commands. The dvgrab command is always the same too. This problem is there for a long time (it is not just in the latest driver). Any ideas? Arne |
From: <Ale...@ne...> - 2000-05-24 14:55:11
|
I am writing a new piece of driver to go on top of OHCI. I generate messages and send them by calling hpsb_write(). My questions are: 1. The hpsb_write() function exists but no-one in the existing stack calls it. Is there any reason for that? 2. Eventuallt hpsb_write() calls hpsb_send_packet() which hangs the kernel before the two calls to down(), even though the semaphore is initialized. This is my major concern now and I will be happy if you have an idea why this happens. 3. Are there any restrictions on using hpsb_write()? Are there prerequisits one has to fulfill before calling it? Thank you, Alex. |
From: Daniel K. <dan...@st...> - 2000-05-24 12:58:15
|
On Tue, 23 May 2000, Jurgen Kramer wrote: > Is it really that simple? I could image the firewire bus is just like a SCSI > bus only serial. I really have to find some more info on how it old works. > Any links? I found some of the old Intel docs and presentations to be quite informative, ftp://ftp.austin.ibm.com/pub/chrptech/1394ohci/, especially 1394ovw.PDF. More rather technical info on specific topics is on http://developer.intel.com/technology/1394/ and http://www.microsoft.com/hwdev/xpapers/pc98/08fire98.htm (Btw. the microsoft site has the only semi-sane CSR description I could get hold of. Short of the $100 IEC/ISO specs that is.) Andreas, maybe some of those links could be mentioned on the linux1394 homepage? Daniel. -- GNU/Linux Audio Mechanics - http://www.glame.de GPG Key ID 89BF7E2B - http://www.keyserver.net |
From: Andreas B. <and...@mu...> - 2000-05-24 11:51:41
|
On Tue, May 23, 2000 at 01:39:42PM -0400, fir...@se... wrote: > Ok, I did the following: > > Machine 1: > insmod ieee1394.o > insmod pcilynx.o > insmod raw1394.o [...] > Machine 1: > insmod eth1394.o > ifup eth3 [...] > Now when I do a ifconfig eth3 I get: > > Machine 1: > eth3 Link encap:Ethernet HWaddr 00:00:69:65:65:00 > inet addr:192.168.3.10 Bcast:192.168.3.255 Mask:255.255.255.0 [...] > Machine 2: > eth3 Link encap:Ethernet HWaddr 00:00:69:65:65:00 > inet addr:192.168.3.11 Bcast:192.168.3.255 Mask:255.255.255.0 [...] > This driver does not rely on any type of card does it? If it does rely on the GUID being unique, then sorry, that's not true for the PCILynx yet. I found nothing in the chip holding the GUID so the PCILynx config ROM contains a fixed GUID for now (and violates the 1394 standard by doing this). -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Andreas B. <and...@mu...> - 2000-05-24 11:50:54
|
On Wed, May 24, 2000 at 05:23:30PM +1000, Stephen Gibson wrote: > > Hi this is probably another one of my dumb questions ... > > If the root node receives a write request with a specific > destination offset, does this mean that the data will be > written to a specific memory location on the root node? Although some 1394 chips can map a window of real memory into the node's address space, all requests are manually interpreted by the subsystem (except for CSR ROM reads on OHCI, as it seems). > My application sends a write request for a data block which specifies > a return destination offset of 0x1000. Any address can be specified, > but this just happens to be one that was snooped. > > Can this address be registered in the root node using some method > in libraw1394 or will I need to resort to the high level routines, such as > used in ether1394.c > hpsb_register_addrspace ? You have to write a kernel module and use hpsb_register_addrspace(). Passing requests to user space would require some architectural change in the subsystem. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: <fra...@ya...> - 2000-05-24 11:18:13
|
--- fir...@se... a écrit : > > > On Tue, 23 May 2000, [iso-8859-1] Franck Bonin > wrote: > > > You should insmod the IEEE 1394 subsystem modules > > (ieee1394.o and > > ohci1394.o) FIRST on ALL the machines. > > > > And then insmod eth1394.o and ifup interfaces on > all > > the machines. > > > > This will fix the problem with HW address. > > Ok, I did the following: > > Machine 1: > insmod ieee1394.o > insmod pcilynx.o > insmod raw1394.o > > Machine 2: > insmod ieee1394.o > insmod pcilynx.o > insmod raw1394.o > > Machine 1: > insmod eth1394.o > ifup eth3 > > Machine 2: > insmod eth1394.o > ifup eth3 > > Now when I do a ifconfig eth3 I get: > > Machine 1: > eth3 Link encap:Ethernet HWaddr 00:00:69:65:65:00 > inet addr:192.168.3.10 Bcast:192.168.3.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:186 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:100 > > Machine 2: > eth3 Link encap:Ethernet HWaddr 00:00:69:65:65:00 > inet addr:192.168.3.11 Bcast:192.168.3.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:186 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:100 > > This driver does not rely on any type of card does > it? > > Judd Tracy > jt...@is... > This is very strange because the last byte of each HW address should be the node number. See line 481 of file eth1384.c : dev->dev_addr[ETH_ALEN-1] = priv->host->node_id & 0x3f; This should works but I haven't tested with pcilynx driver... So I may ask few questions : 1/ Are nodes numbers correctly generated ? (See with gscanbus) 1.1/ If yes, is eth1394 find your card ? (See with dmesg when you insmod eth1394 and send me the output if you want) Card detection is handle by function add_host(), line 354 and cards found are used by function ether1394_init(), near line 735. 1.2/ If no, did you try with the modules I have include with eth1394 archive ? 2/ If the driver init correctly except for HW address, you could assign one to each node yourself line 481. ----- Franck Bonin ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr |
From: Andreas M. <and...@iv...> - 2000-05-24 09:53:48
|
On Wed, May 24, 2000 at 11:32:35AM +0200, stéphane Baier wrote: > I would like to know if the current version of > 1394 linux drivers implements the IP Over 1394 > specification (or part of it) ? No. But it could be implemented on top of the current drivers. -- Andreas Micklei IVISTAR Kommunikationssysteme AG Ehrenbergstr. 19 / 10245 Berlin http://www.ivistar.de |
From: B. <ste...@do...> - 2000-05-24 09:34:33
|
Hi, I would like to know if the current version of 1394 linux drivers implements the IP Over 1394 specification (or part of it) ? Regards, S. Baier. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Stephane BAIER ste...@do... DotCom - Communication Numérique http://www.DotCom.FR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
From: Stephen G. <st...@am...> - 2000-05-24 07:25:12
|
Hi this is probably another one of my dumb questions ... If the root node receives a write request with a specific destination offset, does this mean that the data will be written to a specific memory location on the root node? My application sends a write request for a data block which specifies a return destination offset of 0x1000. Any address can be specified, but this just happens to be one that was snooped. Can this address be registered in the root node using some method in libraw1394 or will I need to resort to the high level routines, such as used in ether1394.c hpsb_register_addrspace ? Thanks for any help, Steve. Background: HP (E8491A) VXI controller, with PC IEEE1394 interface. The snooped data on the IEEE1394 line gave the following annotated transaction, for "abort" sent to a device (Tektronix) in the VXI rack: write request for data block from win95 to HP 0x0 ffc08c10 phys=3c0 tl=23 rt=0 tcode=1 pri=0 0x1 ffc2ffff source=3c2 dest(high)=ffff 0x2 e8000000 dest(low) =e8000000 0x3 1e0000 data_len=1e ext_tcode=0 0x4 5a5d5286 header_CRC 0x5 52002 HP send code 2 0x6 ffff source(high)=ffff 0x7 1000 source(low) =1000 0x8 6 send chars=6 0x9 20001 0xa 1 0xb 61626f72 abor <-- command string 0xc 740a0000 t <-- command string 0xd d1bce49b data_CRC 0xe 10012 final quadlet write response from HP to win95 0x0 ffc28c20 phys=3c2 tl=23 rt=0 tcode=2 pri=0 0x1 ffc00000 source=3c0 rcode=0(resp_complete) reserved=0 0x2 0 reserved 0x3 a93618f3 header_CRC 0x4 10011 final quadlet write request for data block from HP to win95 0x0 ffc29410 phys=3c2 tl=25 rt=0 tcode=1 pri=0 0x1 ffc0ffff source=3c0 dest(high)=ffff 0x2 1000 dest(low) =1000 0x3 c0000 data_len=c ext_tcode=0 0x4 ad396d33 header_CRC 0x5 50000 HP received code 000 0x6 6 received chars=6 0x7 4bff01ff 0x8 ca9c7bec data_CRC 0x9 10012 final quadlet write response from win95 to HP 0x0 ffc09420 phys=3c0 tl=25 rt=0 tcode=2 pri=0 0x1 ffc20000 source=3c2 rcode=0(resp_complete) reserved=0 0x2 0 reserved 0x3 f8834496 header_CRC 0x4 10011 final quadlet For the Linux interface, I use raw1394_start_write to send the data quadlets to the destination offset 0xe8000000: 0x52002 0xffff 0x1000 0x6 0x20001 0x1 0x61626f72 Here is what (dmesg) the kernel traces give, the final packet error code '7' indicates that the "request was send to an address not accessible in the destination node": ieee1394: send packet 400: ffc00110 ffc1ffff e8000000 00200000 ieee1394: send data: 00052002 0000ffff 00001000 00000006 00020001 00000001 61626f72 740a0000 aic5800-0: packet sent with ack code 2 ieee1394: received packet: ffc10020 ffc00000 00000000 00000001 ieee1394: received packet: ffc1f010 ffc0ffff 00001000 000c0000 0005000f 00000000 4bff00ff 00000002 ieee1394: send packet 400: ffc0f120 ffc17000 00000000 aic5800-0: packet sent with ack code 1 |
From: <fir...@se...> - 2000-05-23 17:42:31
|
On Tue, 23 May 2000, [iso-8859-1] Franck Bonin wrote: > You should insmod the IEEE 1394 subsystem modules > (ieee1394.o and > ohci1394.o) FIRST on ALL the machines. > > And then insmod eth1394.o and ifup interfaces on all > the machines. > > This will fix the problem with HW address. Ok, I did the following: Machine 1: insmod ieee1394.o insmod pcilynx.o insmod raw1394.o Machine 2: insmod ieee1394.o insmod pcilynx.o insmod raw1394.o Machine 1: insmod eth1394.o ifup eth3 Machine 2: insmod eth1394.o ifup eth3 Now when I do a ifconfig eth3 I get: Machine 1: eth3 Link encap:Ethernet HWaddr 00:00:69:65:65:00 inet addr:192.168.3.10 Bcast:192.168.3.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:186 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Machine 2: eth3 Link encap:Ethernet HWaddr 00:00:69:65:65:00 inet addr:192.168.3.11 Bcast:192.168.3.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:186 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 This driver does not rely on any type of card does it? Judd Tracy jt...@is... |
From: Mark K. <mk...@co...> - 2000-05-23 16:05:51
|
Physically it really is that simple. Just plug it in. Application wise and driver wise it can be a bit more difficult, but that will get better. Mark -----Original Message----- From: Jurgen Kramer [mailto:GTM...@in...] Sent: Tuesday, May 23, 2000 8:54 AM To: Andreas Micklei Cc: linux1394-devel Subject: Re: What cable is needed? Is it really that simple? I could image the firewire bus is just like a SCSI bus only serial. I really have to find some more info on how it old works. Any links? Thanks, Jurgen Andreas Micklei wrote: > On Tue, May 23, 2000 at 05:38:51PM +0200, Jurgen Kramer wrote: > > I want to connect my two Linux machines together via the firewire bus but > > I'm not sure which cable I need. I guess a standard cable wont work? Do I > > need to buy a firewire hub? > > A standard cable will work. All devices on the IEEE1394 bus are equal. You > only need a hub when you run out of ports. > > > I cant wait to start working on some SPB-2 implemantation... > > Just go ahead. :-) > > -- > Andreas Micklei > IVISTAR Kommunikationssysteme AG > Ehrenbergstr. 19 / 10245 Berlin > http://www.ivistar.de > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux1394-devel _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Jurgen K. <GTM...@in...> - 2000-05-23 15:54:44
|
Is it really that simple? I could image the firewire bus is just like a SCSI bus only serial. I really have to find some more info on how it old works. Any links? Thanks, Jurgen Andreas Micklei wrote: > On Tue, May 23, 2000 at 05:38:51PM +0200, Jurgen Kramer wrote: > > I want to connect my two Linux machines together via the firewire bus but > > I'm not sure which cable I need. I guess a standard cable wont work? Do I > > need to buy a firewire hub? > > A standard cable will work. All devices on the IEEE1394 bus are equal. You > only need a hub when you run out of ports. > > > I cant wait to start working on some SPB-2 implemantation... > > Just go ahead. :-) > > -- > Andreas Micklei > IVISTAR Kommunikationssysteme AG > Ehrenbergstr. 19 / 10245 Berlin > http://www.ivistar.de > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Andreas M. <and...@iv...> - 2000-05-23 15:45:51
|
On Tue, May 23, 2000 at 05:38:51PM +0200, Jurgen Kramer wrote: > I want to connect my two Linux machines together via the firewire bus but > I'm not sure which cable I need. I guess a standard cable wont work? Do I > need to buy a firewire hub? A standard cable will work. All devices on the IEEE1394 bus are equal. You only need a hub when you run out of ports. > I cant wait to start working on some SPB-2 implemantation... Just go ahead. :-) -- Andreas Micklei IVISTAR Kommunikationssysteme AG Ehrenbergstr. 19 / 10245 Berlin http://www.ivistar.de |