linux1394-devel Mailing List for IEEE 1394 for Linux (Page 531)
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
(33) |
Oct
|
Nov
|
Dec
|
From: Andreas M. <and...@iv...> - 2000-05-18 14:57:53
|
Hiho, On Thu, May 18, 2000 at 07:49:03AM -0700, Mark Knecht wrote: > Is anybody working on gscanbus at the moment? I'm finding a number of > problems to report, but I don't want to clog up the reflector with all the > data. > > If anyone is working on it, I'll send it directly to you if requested. > Yes, I still do. I have some other things to do at the moment, therefore releases are coming up very slowly, but I am still working on it. However, I still have enough time for fixing severe bugs or integrating your patches. btw.: Stay tuned for AV/C subunit detection in 0.6. bye... Andreas Micklei -- Andreas Micklei IVISTAR Kommunikationssysteme AG Ehrenbergstr. 19 / 10245 Berlin http://www.ivistar.de |
From: Mark K. <mk...@co...> - 2000-05-18 14:50:15
|
Hi, Is anybody working on gscanbus at the moment? I'm finding a number of problems to report, but I don't want to clog up the reflector with all the data. If anyone is working on it, I'll send it directly to you if requested. Mark |
From: Scott N. <ni...@mi...> - 2000-05-18 06:08:39
|
>Message: 3755037 > FROM: Bruce McDonald > DATE: 05/17/2000 16:07:45 > SUBJECT: RE: Canon AVC Compliance > > Mark, > > I am successfully using a Canon Ultura - I am am in the process of > discovering just what it can do but that is not my primary aim. I am > trying to get libavc1394 working. Please feel free to email me with any > specific questions. > > Bruce. Bruce, I am considering using a Cannon Optura, Could you make any sample code available? Scott |
From: Ken S. <ke...@tu...> - 2000-05-18 05:19:42
|
Jun Sun wrote: > > Try to set LD_LIBRARY_PATH. In csh, do 'setenv > LD_LIBRARY_PATH /usr/local/lib'. In bash, do 'export > LD_LIBRARY_PATH=/usr/local/lib'. > > Jun A more permanent fix would be to edit /etc/ld.so.conf and add /usr/local/lib, then run ldconfig. This updates /etc/ld.so.cache and you won't have to use LD_LIBRARY_PATH anymore. |
From: Ken S. <ke...@tu...> - 2000-05-18 05:09:47
|
Jun Sun wrote: > > Try to set LD_LIBRARY_PATH. In csh, do 'setenv > LD_LIBRARY_PATH /usr/local/lib'. In bash, do 'export > LD_LIBRARY_PATH=/usr/local/lib'. > > Jun A more permanent fix would be to edit /etc/ld.so.conf and add /usr/local/lib, then run ldconfig. This updates /etc/ld.so.cache and you won't have to use LD_LIBRARY_PATH anymore. |
From: Mark K. <mk...@co...> - 2000-05-17 23:23:06
|
Jun & Steven, Thanks. That works. I am now getting gscanbus windows open on the screen and in some cases can read registers on the bus. Mark -----Original Message----- From: Jun Sun [mailto:jul...@ya...] Sent: Wednesday, May 17, 2000 3:24 PM To: Mark Knecht; Linux1394 Developer's Reflector (E-mail) Subject: Re: Attempting gscanbus --- Mark Knecht <mk...@co...> wrote: > 8) When I try and run gscanbus, I see this: > > > [root@bambi gscanbus-0.5]# ./gscanbus > ./gscanbus: error in loading shared libraries: > libraw1394.so.2: cannot open > shared object file: No such file or directory > [root@bambi gscanbus-0.5]# > Try to set LD_LIBRARY_PATH. In csh, do 'setenv LD_LIBRARY_PATH /usr/local/lib'. In bash, do 'export LD_LIBRARY_PATH=/usr/local/lib'. Jun __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ |
From: Bruce M. <br...@tr...> - 2000-05-17 23:09:29
|
Mark, I am successfully using a Canon Ultura - I am am in the process of discovering just what it can do but that is not my primary aim. I am trying to get libavc1394 working. Please feel free to email me with any specific questions. Bruce. On Wed, 17 May 2000, Mark Knecht wrote: > Is anyone using the Canon Ultura camcorder yet with the Linux 1394 stack? It > has a DV out, 4-pin 1394 connector, but the documentation I could dig up > didn't specifically say anything about what command set it supports. > > If not this Canon, is anyone using any other Canon model? > > Thanks > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux1394-devel > |
From: Jun S. <jul...@ya...> - 2000-05-17 22:25:11
|
--- Mark Knecht <mk...@co...> wrote: > 8) When I try and run gscanbus, I see this: > > > [root@bambi gscanbus-0.5]# ./gscanbus > ./gscanbus: error in loading shared libraries: > libraw1394.so.2: cannot open > shared object file: No such file or directory > [root@bambi gscanbus-0.5]# > Try to set LD_LIBRARY_PATH. In csh, do 'setenv LD_LIBRARY_PATH /usr/local/lib'. In bash, do 'export LD_LIBRARY_PATH=/usr/local/lib'. Jun __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ |
From: Mark K. <mk...@co...> - 2000-05-17 21:25:22
|
Manfred, The OHCI spec (Clause 11 in the 1.06 revision) specifies a 'SelfID Buffer Pointer Register' and 'SelfID Count Register'. My presumption is that these register are programmed prior to doing a bus reset, and then the SelfID packets are stored there by the OHCI controller. The registers are at offsets h064 & h068 respectively. Presumably you could read out the pointer address and go to memory to find the SelfID packets, and then make your determinations from what is stored there. Alternatively, you might just hunt & peck across the bus looking for features in a give device. Since you know the root ID, at least you have an upper bound...... Mark -----Original Message----- From: Manfred Weihs [mailto:e95...@st...] Sent: Wednesday, May 17, 2000 3:31 AM To: Franck Bonin Cc: Linux1394 devel Subject: Re: detection of isochronous resource manager Franck Bonin wrote: > Just look at self-ID packets : > > If bit 'c' and 'L'(11 & 22) are set to one, the > corresponding node is condidate to be the isochronous > resource manager. And the isochronous res manager is > the candidate node with the largest phy ID (bits > 24~29) This sounds reasonable, but there is one problem: Where do I find the self-ID packets? I have to read the topology map for that purpose, but not the topology map at the local node, but that one on the bus manager, because that is the only one which is guaranteed to have valid data. So I first have to find out the id of the bus manager. For that purpose, I think, I can read the bus_manager_id register of the local node. But the problem is, that it is possible, that we have no bus manager (ie bus manager id is 0x3f). In that case, I think (but I am not quite sure) I should read the topology map of the isochronous resource manager (which does some tasks of the bus manager). So it might be necessary to know the id of the isochronous resource manager in order to find out the id of the isochronous resource manager! So there must be another way to find out the id of the isochronous resource manager. _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Mark K. <mk...@co...> - 2000-05-17 21:03:45
|
Is anyone using the Canon Ultura camcorder yet with the Linux 1394 stack? It has a DV out, 4-pin 1394 connector, but the documentation I could dig up didn't specifically say anything about what command set it supports. If not this Canon, is anyone using any other Canon model? Thanks |
From: Manfred W. <e95...@st...> - 2000-05-17 20:12:50
|
Franck Bonin wrote: > Just look at self-ID packets : > > If bit 'c' and 'L'(11 & 22) are set to one, the > corresponding node is condidate to be the isochronous > resource manager. And the isochronous res manager is > the candidate node with the largest phy ID (bits > 24~29) This sounds reasonable, but there is one problem: Where do I find the self-ID packets? I have to read the topology map for that purpose, but not the topology map at the local node, but that one on the bus manager, because that is the only one which is guaranteed to have valid data. So I first have to find out the id of the bus manager. For that purpose, I think, I can read the bus_manager_id register of the local node. But the problem is, that it is possible, that we have no bus manager (ie bus manager id is 0x3f). In that case, I think (but I am not quite sure) I should read the topology map of the isochronous resource manager (which does some tasks of the bus manager). So it might be necessary to know the id of the isochronous resource manager in order to find out the id of the isochronous resource manager! So there must be another way to find out the id of the isochronous resource manager. |
From: Mark K. <mk...@co...> - 2000-05-17 18:05:45
|
Hi, I'm having some (hopefully) simple startup problems. Can someone point out what I'm doing wrong? gscanbus says it can't find libraw1394, but it appears to be there..... Thanks, Mark 1) I have set up a dedicated machine for testing Linux 1394. 2) I've attempted to build the 2.2.15 kernel with 1394 support. Lilo allows me to boot the new kernel. I think 1394 support is loaded as the following is the result of a dmesg command: ieee1394: registered ohci1394 driver, initializing now ohci1394: looking for Ohci1394 cards ohci1394_0: allocated interrupt 10 ohci1394_0: The 1st byte at offset 0x404 is: 0x31 ohci1394_0: remapped memory spaces reg 0xc2800000 ohci1394_0: soft reset finished ohci1394_0: max packet size = 2048 bytes ohci1394_0: 4 iso contexts available ohci1394_0: Receive DMA ctx=2 initialized ohci1394_0: Receive DMA ctx=0 initialized ohci1394_0: Receive DMA ctx=1 initialized ohci1394_0: AT dma ctx=0 initialized ohci1394_0: AT dma ctx=1 initialized ohci1394_0: Cancel request received ohci1394_0: resetting bus on request and attempting to become root ieee1394: detected 1 ohci1394 adapter ohci1394_0: Got RQPkt interrupt status=0x00008409 ohci1394_0: SelfID process finished (phyid 1, not root) ohci1394_0: selfid packet 0x807f4658 rcvd ieee1394: including selfid 0x58467f80 ohci1394_0: selfid packet 0x817f8466 rcvd ieee1394: including selfid 0x66847f81 ohci1394_0: This node self-id is 0x817f8466 ohci1394_0: selfid packet 0x827f40dc rcvd ieee1394: including selfid 0xdc407f82 ohci1394_0: calling self-id complete ohci1394_0: Got phy packet ctx=0 ... discarded ieee1394: 1 host adapter initialized ohci1394_0: request csr_rom address: C1FBF000 (Subsequent dmesg and /var/log/messages reflect bus activity when I add or remove devices...) 3) I have 3 devices on the bus - Linux PC, Philips 1394AV Reference Kit, Sony CCMDS-250 camera. There appear to be three devices recognized above. 4) In the past I though I needed to 'insmod' something, but I can't find directions on that step, so I haven't done anything. 5) lsmod reports nothing loaded. Is this the problem? 6) I've installed libraw1394: [root@bambi gscanbus-0.5]# cd /usr/local/lib [root@bambi lib]# dir total 132 drwxr-xr-x 2 root root 4096 May 15 16:11 . drwxr-xr-x 12 root root 4096 May 15 16:11 .. -rw-r--r-- 1 root root 74016 May 15 16:11 libraw1394.a -rwxr-xr-x 1 root root 660 May 15 16:11 libraw1394.la lrwxrwxrwx 1 root root 19 May 15 16:11 libraw1394.so -> libraw1394.so.2.1.0 lrwxrwxrwx 1 root root 19 May 15 16:11 libraw1394.so.2 -> libraw1394.so.2.1.0 -rwxr-xr-x 1 root root 37032 May 15 16:11 libraw1394.so.2.1.0 [root@bambi lib]# 7) The Makefile for gscanbus seemed to be setup to point at libraw1394: <snip> # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software Foundation, # Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # INCLUDE=-I. -I/usr/local/include/libraw1394 CFLAGS=$(INCLUDE) -g -Wall #LIBPATH=-L/usr/local/src/libraw1394-0.6 LIBPATH=-L/usr/local/lib all: gscanbus <end-snip> 8) When I try and run gscanbus, I see this: [root@bambi gscanbus-0.5]# ./gscanbus ./gscanbus: error in loading shared libraries: libraw1394.so.2: cannot open shared object file: No such file or directory [root@bambi gscanbus-0.5]# |
From: Bruce M. <br...@tr...> - 2000-05-17 02:03:43
|
Andreas, All, I have a SRPM of libraw1394-0.6 - It seems to work fine but please check it out y'all. I will be doing libavc next. regards, Bruce http://home.carolina.rr.com/libraw1394-0.6-1.src.rpm -- On Mon, 15 May 2000, Andreas Bombe wrote: > On Sun, May 14, 2000 at 09:52:23AM -0400, Bruce McDonald wrote: > > PS. I will be RPMizing this library - is there anyone doing this for > > libraw1394 or should I be doing this one too. > > Would be nice. I'm using Debian so I will create Debian packages of > libraw (already got some packages built). RPM specs targeted for > RedHat, SuSE and others are welcome. > > |
From: Andreas B. <and...@mu...> - 2000-05-16 18:43:37
|
On Sun, May 14, 2000 at 06:33:40PM -0700, Serguei Panskikh wrote: > Does anyone knows the way how to mount FireWire Zip drive in the linux? We don't have the drivers for that yet. I guess it uses SBP-2 as its protocol, and there is no such driver yet (though it is being worked on). -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Ichiro S. <ic...@fn...> - 2000-05-16 18:16:47
|
Hi, I'm tring to use IEEE1394 to connect two PCs. When I start the OHCI driver on one machine, the driver doesn't recognize the card at the other end. I had messages like; ohci1394_0: IntEvent: 00020000 ... many of these ... ohci1394_0: IntEvent: 00020000 ohci1394_0: IntEvent: 00000000 ohci1394_0: IntEvent: 00010000 ohci1394_0: SelfID process finished (phyid 2, root) ohci1394_0: selfid packet 0x803f8464 rcvd ieee1394: including selfid 0x64843f80 ohci1394_0: selfid packet 0x827f845e rcvd ieee1394: including selfid 0x5e847f82 ohci1394_0: This node self-id is 0x827f845e ohci1394_0: calling self-id complete ieee1394: SelfIDs failed monotony check with 2 ieee1394: stopping out-of-control reset loop ieee1394: warning - topology map and speed map will therefore not be valid ohci1394_0: IntEvent: 00000000 ohci1394_0: Got phy packet ctx=0 ... discarded ... many of these ... ohci1394_0: Got phy packet ctx=0 ... discarded Please tell me your guess on what's wrong. My configurations are; o PIII PCs o D-LINK NIC (TI's chips) o 20000318 release of the patch o ohci1394.o and ieee1394.o both 20000318 and CVS version of today. |
From: Manfred W. <e95...@st...> - 2000-05-16 17:01:48
|
Hi! I have one simple(?) question: Does anybody know an easy way to find out the id of the isochronous resource manager using libraw1394? Manfred Weihs |
From: <fra...@ya...> - 2000-05-16 09:24:56
|
Here is my small program that emulate a Tape Recorder/player unit : http://www.chez.com/kayle/IEEE_1394/virtual_vcr_0.0.1.tgz It can only recording data using another program like dvgrab or capture. This program handle a small set of commands sent to a Tape Recorder/player and send responds. This make believe other computer that there is a Tape Recorder/player on the bus, so they can output iso data. TO USE IT you have to : 1. Change the ROM of your IEEE 1394 driver : see file ROM. 2. Rebuild the driver. 3. "insmod" the new driver and launch the Virtual_VCR program. 4. You can see if it work by using gscanbus : it will show a VCR instead of a terminal. HOW TO BUILD Virtual_VCR : Type "make" You can test your virtual VCR if you use another computer. I am using an iMac DV with iMovie, both belive that my PC-linux is a Tape Recorder/player. And I can record movie from the iMac using dvgrab or capture. --- Franck Bonin http://www.chez.com/kayle/IEEE_1394/virtual_vcr_0.0.1.tgz --- 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 |
From: <fra...@ya...> - 2000-05-16 08:24:10
|
Trying to reciving video from other computer, I have built a small program, I named capture, that can grab and play DV data at the same time. It use both dvgrab and libdv algorithms. IT IS NOW AAVAILLABLE AT http://www.chez.com/kayle/IEEE_1394/capture_0.0.1.tgz This is part of the README file from capture_0.0.1 : Capture is a program that can grab and play DV data at the same time. It use both dvgrab and libdv algorithms. I have include libdv with a very few modified version of playdv.c in the subdirectory named libdv. HOW TO BUILD : 1. In the libdv subdirectory : just type "make". You will obtain playdv with a new feature. 2. In the main directory : type "make". This build capture. Type "capture --help" for more informations. HOW TO USE : To use capture just type "capture" and it will grab and play the NTSC movie that your CamRecorder is curently playing. (there is lot of option to) Note that the grabber is fast BUT the decoder is slow. On my PII 300Mhz I lose one frame on two during playing. Note : playing PAL movie shouldn't be hard but I haven't tested. So Try to adjust 'TAILLE_BUFF_LECTURE' in double_buffer.h if you want. NEW IN PLAYDV : Now you can use pipes, this should works : ./capture --noview --o --frames 500 | ./libdv/playdv and dvgrab --dv --ntsc --frames 500 test OR ./capture --noview --of test --frames 500 cat test.dv | ./libdv/playdv Should produce the same result. Enjoy ! ---- Franck Bonin ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr |
From: Mark K. <mk...@co...> - 2000-05-15 23:33:31
|
I have in front of me a 1394 camera which purports to be: 1) Compatible with 1394-1995 2) Supports the 'Digital Camera Specification, Revision 1.04' 3) VGA (640X480, Non-Compressed YUV Digital Output 4) 30 FPS Would this camera be compatible with the current set of drivers and applications? Thanks. |
From: <fir...@se...> - 2000-05-15 17:57:14
|
Does anyone know if there is a web page or other source of information about IP over 1394 anywere. I am interested in learning and testing. I have a few machines linked together that I would like to play with. Judd Tracy jt...@is... |
From: Serguei P. <spa...@se...> - 2000-05-15 01:34:42
|
Does anyone knows the way how to mount FireWire Zip drive in the linux? more precisely: I have a Powerbook G3 '99 with PCMCIA slot that I use for Firewire (Orange Link) or USB (OHCI) cards to have an access to Zip drives (VST/Firewire and Iomega/USB). In MacOS I have no either problem. In Linux in both cases I cannot mount Zip drives. Does anybody the way how to do it? Any links to documentation aslo would be appreciated. Thank you, Serguei |
From: Andreas B. <and...@mu...> - 2000-05-14 22:46:54
|
I was busy learning the last week, but I should be able to work more on the subsystem again... I have put some code to collect GUIDs from connected nodes on CVS. It is not complete yet, but it works somehow. On a bus reset, the code reads the GUIDs from all connected active nodes and stores them in a list. Entries in those list can be referenced through a function and used to fill in the target address in a hpsb_packet. As said it's not complete yet, things missing: - Doesn't work reliably with multiple 1394 cards in the system. - No way to dereference/free handles yet. - Should retry transactions. - Reliable node offline report. - Some interface from raw1394 It should give a first idea of how to lock on a node with a certain GUID. This would be especially interesting to the folks implementing SBP-2. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Jun S. <jul...@ya...> - 2000-05-14 22:38:43
|
This is about gscanbus. Please let me if there is a more appropriate mailing to talk about gscanbus. I tried the latest versions of gscanbus/libraw/kernel patch, (See the subject) and still have a couple of problems : 1. Right after I started the computer, if I don't connect my camcorder, gscanbus cannot read topology map : duanduan:~/1394/gscanbus/gscanbus-0.5% gscanbus successfully got handle current generation number: 1 using first card found: 1 nodes on bus, local ID is 0 Could not read topologyMap The strange thing is after I connected the camcorder and even if I removed the camcorder again, gscanbus would be able to start just fine. 2. When I plug and unplug the 1394 cable, occasionally it will crash and gives core dump : Bus reset - current generation number: 27 Root Directory length: 5 Unknown key/value pair 0x8d 0x000009 Unknown key/value pair 0xc3 0x000004 Reading Unit directory: 0 0x0000fffff000042c Unit Directory length: 2 Root Directory length: 9 Unknown key/value pair 0x8d 0x00000e Unknown key/value pair 0xc7 0x000010 Unknown key/value pair 0x04 0x000000 Unknown key/value pair 0x09 0x000000 Root Directory length: 5 Unknown key/value pair 0x8d 0x000009 Unknown key/value pair 0xc3 0x000004 Reading Unit directory: 0 0x0000fffff000042c Unit Directory length: 2 Root Directory length: 9 Unknown key/value pair 0x8d 0x00000e Unknown key/value pair 0xc7 0x000010 Unknown key/value pair 0x04 0x000000 Unknown key/value pair 0x09 0x000000 Root Directory length: 5 Unknown key/value pair 0x8d 0x000009 Unknown key/value pair 0xc3 0x000004 Reading Unit directory: 0 0x0000fffff000042c Unit Directory length: 2 Root Directory length: 9 Unknown key/value pair 0x8d 0x00000e Unknown key/value pair 0xc7 0x000010 Unknown key/value pair 0x04 0x000000 Unknown key/value pair 0x09 0x000000 Root Directory length: 5 Unknown key/value pair 0x8d 0x000009 Unknown key/value pair 0xc3 0x000004 Reading Unit directory: 0 0x0000fffff000042c Unit Directory length: 2 Root Directory length: 9 Unknown key/value pair 0x8d 0x00000e Unknown key/value pair 0xc7 0x000010 Unknown key/value pair 0x04 0x000000 Unknown key/value pair 0x09 0x000000 Root Directory length: 5 Unknown key/value pair 0x8d 0x000009 Unknown key/value pair 0xc3 0x000004 Reading Unit directory: 0 0x0000fffff000042c Unit Directory length: 2 Root Directory length: 9 Unknown key/value pair 0x8d 0x00000e Unknown key/value pair 0xc7 0x000010 Unknown key/value pair 0x04 0x000000 Unknown key/value pair 0x09 0x000000 Root Directory length: 5 Unknown key/value pair 0x8d 0x000009 Unknown key/value pair 0xc3 0x000004 Reading Unit directory: 0 0x0000fffff000042c 0/0x0000fffff000042c: read failed Bus reset - current generation number: 28 Segmentation fault (core dumped) Hopefully these bug reports help. Let me know if you need more information. BTW, my driver is OHCI driver. My camcorder is Sony TRV510. Jun |
From: Andreas B. <and...@mu...> - 2000-05-14 22:13:41
|
On Sun, May 14, 2000 at 09:52:23AM -0400, Bruce McDonald wrote: > PS. I will be RPMizing this library - is there anyone doing this for > libraw1394 or should I be doing this one too. Would be nice. I'm using Debian so I will create Debian packages of libraw (already got some packages built). RPM specs targeted for RedHat, SuSE and others are welcome. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Daniel K. <dan...@st...> - 2000-05-14 16:35:55
|
On Sun, 14 May 2000, Sebastien Rougeaux wrote: > Thanks for the patch. Any luck with the SONY chip ? Not as much as I'd like to. As I wrote on Friday, there's clearly life on the bus but that's about all I see. Anyway, I've found the cause - or a workaround at least - for the OHCI module hanging my machine when I insmod it the second time: First of all, stop_context() gives me runaway loops upon rmmod. On the next insmod, the chip will lock the machine (well, the PCI bus most probably) when isoRecvIntMask is set to 0x1. I'm not sure why, but I suspect that setting the mask activates the context. The associated program however is not yet initialized. So once again I moved a bit of code around to locations that looked sane to me. I also made sure all iso recv interrupts are cleared on initialization. reg_read()/reg_write() contain some #ifdef'd code to track down such PCI lock ups; maybe someone will find this useful one day. Regards, Daniel. --[snip]-- Index: ohci1394.c =================================================================== RCS file: /cvsroot/linux1394/ieee1394/ohci1394.c,v retrieving revision 1.29 diff -u -r1.29 ohci1394.c --- ohci1394.c 2000/05/14 02:21:11 1.29 +++ ohci1394.c 2000/05/14 16:13:27 @@ -1088,8 +1088,8 @@ reg_write(ohci, OHCI1394_LinkControlSet, 0x00300000); /* Clear interrupt registers */ - reg_write(ohci, OHCI1394_IntEventClear, 0xffffffff); reg_write(ohci, OHCI1394_IntMaskClear, 0xffffffff); + reg_write(ohci, OHCI1394_IntEventClear, 0xffffffff); /* Set up self-id dma buffer */ reg_write(ohci, OHCI1394_SelfIDBuffer, @@ -1156,6 +1156,18 @@ /* Clear the interrupt mask */ reg_write(ohci, OHCI1394_IsoRecvIntMaskClear, 0xffffffff); + reg_write(ohci, OHCI1394_IsoRecvIntEventClear, 0xffffffff); + + /* Initialize AR dma */ + initialize_dma_rcv_ctx(ohci->ar_req_context); + initialize_dma_rcv_ctx(ohci->ar_resp_context); + + /* Initialize AT dma */ + initialize_dma_trm_ctx(ohci->at_req_context); + initialize_dma_trm_ctx(ohci->at_resp_context); + + /* Initialize IR dma */ + initialize_dma_rcv_ctx(ohci->ir_context); /* Set up isoRecvIntMask to generate interrupts for context 0 (thanks to Michael Greger for seeing that I forgot this) */ @@ -1197,17 +1209,6 @@ /* Enable link */ reg_write(ohci, OHCI1394_HCControlSet, 0x00020000); - - /* Initialize AR dma */ - initialize_dma_rcv_ctx(ohci->ar_req_context); - initialize_dma_rcv_ctx(ohci->ar_resp_context); - - /* Initialize AT dma */ - initialize_dma_trm_ctx(ohci->at_req_context); - initialize_dma_trm_ctx(ohci->at_resp_context); - - /* Initialize IR dma */ - initialize_dma_rcv_ctx(ohci->ir_context); return 1; } Index: ohci1394.h =================================================================== RCS file: /cvsroot/linux1394/ieee1394/ohci1394.h,v retrieving revision 1.15 diff -u -r1.15 ohci1394.h --- ohci1394.h 2000/05/14 02:21:11 1.15 +++ ohci1394.h 2000/05/14 16:13:27 @@ -221,12 +221,38 @@ */ inline static void reg_write(const struct ti_ohci *ohci, int offset, u32 data) { +#ifdef OHCI1394_EXCESSIVE_DEBUG + printk(KERN_CRIT "ohci%d: Writing 0x%08x to register 0x%04x.\n", + ohci->id, data, offset); + /* To track down a lockup, other processes must be given a + * chance to display the printk output! + */ + if (!in_interrupt()) + schedule(); writel(data, ohci->registers + offset); + printk(KERN_CRIT "ohci%d: Write done.\n", ohci->id); +#else + writel(data, ohci->registers + offset); +#endif } inline static u32 reg_read(const struct ti_ohci *ohci, int offset) { - return readl(ohci->registers + offset); +#ifdef OHCI1394_EXCESSIVE_DEBUG + u32 tmp; + printk(KERN_CRIT "ohci%d: Reading from register 0x%04x.\n", + ohci->id, offset); + /* To track down a lockup, other processes must be given a + * chance to display the printk output! + */ + if (!in_interrupt()) + schedule(); + tmp = readl(ohci->registers + offset); + printk(KERN_CRIT "ohci%d: Read 0x%08x.\n", ohci->id, tmp); + return tmp; +#else + return readl(ohci->registers + offset); +#endif } /* This structure is not properly initialized ... it is taken from |