linux1394-devel Mailing List for IEEE 1394 for Linux (Page 542)
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 B. <and...@mu...> - 2000-03-18 18:08:18
|
On Sat, Mar 18, 2000 at 02:47:20PM +0100, Manfred Weihs wrote: > Andreas Bombe wrote: > > Run aclocal and then again autoconf. > > aclocal says: > aclocal: configure.in: 7: macro `AM_PROG_LIBTOOL' not found in library Seems the correct sequence would be aclocal, automake --add-missing and then autoconf. There is an autogen.sh script in the repository now, it created Makefiles from a bare CVS checkout from me just fine. Running that should do the right thing (the script is taken from GLib, so it's well tested). -- Andreas E. Bombe <and...@mu...> http://home.pages.de/~andreas.bombe/ DSA key 0x04880A44 |
From: Manfred W. <e95...@st...> - 2000-03-18 13:52:35
|
Andreas Bombe wrote: > Run aclocal and then again autoconf. aclocal says: aclocal: configure.in: 7: macro `AM_PROG_LIBTOOL' not found in library The problem remains. Manfred Weihs |
From: Sebastien R. <Seb...@sy...> - 2000-03-18 05:12:19
|
>>>>> "Jeffrey" == Jeffrey B Mulligan <jb...@vi...> writes: Jeffrey> I went to the link you sent me (at your site) and it sent me to Jeffrey> sourceforge... I got the latest 2.2.14 patch from there (the Jeffrey> february one), but the behavior is pretty much the same as I was Jeffrey> seeing with the january patch. The basic problem is that the driver Jeffrey> sees the card but doesn't see any nodes. No no... don't get only the patch, get the latest ohci module from the cvs tree ! Just follow the instructions on how to download using cvs, and then you should be able to stay up to date with the latest changes. Jeffrey> One thing I noticed is that the interrupt handler is getting called a Jeffrey> lot with event=0... the IRQ is shared with other cards, does that Jeffrey> mean that handler will be called when one of the other sharing boards Jeffrey> generates an interrupt? I am not completely sure about that. If the interrupt handler is called with event=0, then nothing should happen and so no problem should be generated. But I thought that even if the interrupt is shared with another device, the interrupt handler is only called when the corresponding device generate an interrupt... I should verify that in the doc. Jeffrey> I also noticed that the node count gets set after an interrupt occurs Jeffrey> with a selfid complete event... I couldn't determine what is Jeffrey> supposed to make this happen, but it never does. There is a known bug in the driver (documented in the top of the file). If you load the modules when no devices are connected on the bus, then later on when you plug a device, the self-ids might not be received properly. I haven't found the cause for this yet, but as a result the node count is not incremented. But if you load the ohci1394 module when at least one device is plugged, then it should be fine afterwards... Jeffrey> Perhaps the wrong irq is being detected? On my system the irq's get Jeffrey> remapped to numbers > 16. This caused me some problems with another Jeffrey> driver I was working with (for an analog frame grabber), which was Jeffrey> reading the irq from the pci config space register, instead of using Jeffrey> the new improved method of getting it from the system's pci_dev Jeffrey> struct. I see that this is done correctly in the ohci driver, Jeffrey> though... IRQ > 15 ... Don't know about that either (I am not a real linux kernel guru). what does the /proc/interrupts say ? What does the dmesg say after you load the ohci module. Jeffrey> One other possibility - I am running on a dual-processor motherboard Jeffrey> with SMP enabled. Has the driver been tested under SMP? I suppose I Jeffrey> could rebuild my kernel with SMP turned off and see if it makes any Jeffrey> difference. Everything else involving SMP has worked so well I am Jeffrey> doubtful that this is the culprit. I also have a dual PIII here with SMP enabled, and the ohci driver runs fine so far. Jeffrey> I also discovered /proc/ohci but I don't really understand yet how to Jeffrey> interpret the output... It is just a way for me to easily debug the driver. Its main role is to print the ohci registers, plus some internal variables of the driver... you can modify its behavior to print whatever you want. Jeffrey> Any suggestions you can provide will be greatly appreciated; I Jeffrey> prepared to try a different card if that might help... First download the latest ohci module from cvs at sourceforge. Then plug a 1394 device to your card. Then load the ohci module into the kernel and see what dmesg says. If you still have trouble contact me (and forward your post to the list). -- Sebastien Rougeaux RSISE, The Australian National University |
From: Andreas B. <and...@mu...> - 2000-03-18 03:40:14
|
On Fri, Mar 17, 2000 at 01:17:18PM +0000, Andreas Pomi wrote: > Hi, > > because of crashes of our camera monitoring (Ximage) application to > display the output of > a Sony DFW-V(L)500 i had to remove the logging of incoming iso packets. > Would be nice > to have a central mechanism of #defines to enable/disable the different > categories of messages > (error, debug, info...) of all modules... I added a config option for "excessive debugging" and made e.g. the dumping of every packet header dependent on that. I also cleaned up PCILynx logging, for OHCI I just made the OHCI1394_DEBUG define dependent on CONFIG_IEEE1394_VERBOSEDEBUG. I think that should do what you want. -- Andreas E. Bombe <and...@mu...> http://home.pages.de/~andreas.bombe/ DSA key 0x04880A44 |
From: Andreas B. <and...@mu...> - 2000-03-18 02:02:01
|
On Fri, Mar 17, 2000 at 06:18:07PM +0100, Manfred Weihs wrote: > Andreas Bombe wrote: > > ..., so > > do a new checkout if you did already. > > I called "automake -a" (because automake without options complained > about missing files) and then "autoconf". > Afterwards I tried to start ./configure, but it said: > ./configure: line 524: syntax error near unexpected token > `AM_INIT_AUTOMAKE(libraw1394,' > ./configure: line 524: `AM_INIT_AUTOMAKE(libraw1394, 0.5)' Run aclocal and then again autoconf. I know, I will put a GNOME style autogen.sh script into the repository that automates that... -- Andreas E. Bombe <and...@mu...> http://home.pages.de/~andreas.bombe/ DSA key 0x04880A44 |
From: Manfred W. <e95...@st...> - 2000-03-17 17:23:16
|
Andreas Bombe wrote: > ..., so > do a new checkout if you did already. I used the cvs server the first time (before I only downloaded the tarballs), and I have a problem to compile libraw1394. Do I need special versions of automake and autoconf (I have automake 1.4 and autoconf 2.13). I called "automake -a" (because automake without options complained about missing files) and then "autoconf". Afterwards I tried to start ./configure, but it said: ./configure: line 524: syntax error near unexpected token `AM_INIT_AUTOMAKE(libraw1394,' ./configure: line 524: `AM_INIT_AUTOMAKE(libraw1394, 0.5)' Manfred Weihs |
From: <fra...@ya...> - 2000-03-17 15:45:33
|
Hi all, I would like to play with isochronous transactions with Linux 1394 . I currently have two adaptec HotConnect 8920 cards. But since insochronous transfers are not support under linux for such cards, I think I should better use other cards. I think OHCI card is a good choice ... (isn't it??) But, if somebody knows an OHCI card which works well under linux, this will help me to make a choice before buying anything. Franck ------ ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr |
From: Andreas B. <and...@mu...> - 2000-03-17 03:31:33
|
On Thu, Mar 16, 2000 at 04:37:27PM -0700, Bowles, Karl wrote: > Unibrain: > speed_map[x] | speed setting > where x = | > -----------------------|------------------------ > 56 | S400 > 61 | S400 [big snip losing context] > 127 | S400 > 184 | S400 > all others | 0x00 Our drivers indicate all other's are at > S100 > > When I figure it out: > speed_code[i]=speed_code[j]; where [i]=64 x m + n & [j] = 64 x n + m > with > m | n => i | j > ---------|---------- --------|------- > 0 | 0 0 | 0 > 0 | 1 1 | 64 > 0 | 2 2 | 128 > 1 | 0 64 | 1 > 1 | 1 65 | 65 > 1 | 2 66 | 129 > 2 | 0 128| 2 > 2 | 1 129| 66 > 2 | 2 130| 130 These i and j indexes are the only legal to read in your 3 node setup. I'm not sure what you accessed in your two examples and I don't know what the problem is. > What did I do wrong? Our software agrees better with Unibrain's, but none of > the three possibilities agree fully. Also, the way I did it looks like it > will work until, but it is not that simple. Do they disagree anywhere inside the legal indexes? > I know you HAVE to implement the > topology tree so that you can set the speed at each of the locations to the > speed of the slowest node on the path from one point in the tree to the > next. My algorithm presets the map to S400 and eliminates impossible speeds. Without explicitly creating a tree and using the information in place instead. I hand-verified my algorithm with a number of test cases (9 node setups) through a test program which displays the speed map and it gives correct results. > In my case, all the nodes are S400 capable so it is a trivial case. And there certainly shouldn't be a problem with my algorithm in that case. > Should the Linux driver software use the 0x0f convention of indicating there > is not node at a location? It doesn't matter. Speed codes outside those referring to existing nodes are undefined by 1394-1995. In Linux they start out as zero and then just contain what they had last written to. -- Andreas E. Bombe <and...@mu...> http://home.pages.de/~andreas.bombe/ DSA key 0x04880A44 |
From: Andreas B. <and...@mu...> - 2000-03-16 22:41:46
|
On Thu, Mar 16, 2000 at 07:16:35PM +0100, Manfred Weihs wrote: > Andreas Bombe wrote: > > I added highlevel handling of the FCP_COMMAND and FCP_RESPONSE > > registers to the subsystem. Reads to those registers are > > unimplemented, written data will be passed to a highlevel fcp request > > stream (similarily to the way iso data is handled). > > Great! I will test this in the next few weeks! I just fixed a bug in libraw where it never started FCP monitoring, so do a new checkout if you did already. I also added a small FCP test to testlibraw. -- Andreas E. Bombe <and...@mu...> http://home.pages.de/~andreas.bombe/ DSA key 0x04880A44 |
From: Jeffrey B. M. <jb...@vi...> - 2000-03-16 20:00:25
|
Hi, I posted a few days ago with some problems, the software is seeing 1 card but no nodes. I am working with kernel 2.2.14, and upgraded to the 2/21 patch to get the latest drivers. Right now I am just working with testlibraw, because gscanbus hangs are requires a reboot to clear. (see postscript for notes on odd gscanbus behavior.) I have been trying to understand how the driver works by inserting printk's in every function to get an idea of the sequence of events. I have figured out that host->node_count gets set after a selfIDComplete interrupt, which is never occurring. I have not been able to determine where is the event or request that is supposed to trigger this... My card is ADS Pyro (TI chip?), I have a Canon DV camera connected... thanks in advance, Jeff p.s. gscanbus draws some stuff to its window that is badly sheared, as if the image data being loaded has the wrong dimensions for the window. (This is when I use a sun workstation running an old version of sunOS as my X server; I tried it on the linux PC host that has the card, and just got a black window...) I have traced the execution to the call to gtk_main(). |
From: Manfred W. <e95...@st...> - 2000-03-16 18:21:57
|
Andreas Bombe wrote: > I added highlevel handling of the FCP_COMMAND and FCP_RESPONSE > registers to the subsystem. Reads to those registers are > unimplemented, written data will be passed to a highlevel fcp request > stream (similarily to the way iso data is handled). Great! I will test this in the next few weeks! Manfred Weihs |
From: Andreas B. <and...@mu...> - 2000-03-16 04:06:25
|
I added highlevel handling of the FCP_COMMAND and FCP_RESPONSE registers to the subsystem. Reads to those registers are unimplemented, written data will be passed to a highlevel fcp request stream (similarily to the way iso data is handled). raw1394 uses this to pass requests to libraw1394, which has the following new interfaces: typedef int (*fcp_handler_t)(raw1394handle_t, nodeid_t nodeid, int response, size_t length, unsigned char *data); fcp_handler_t raw1394_set_fcp_handler(raw1394handle_t, fcp_handler_t); int raw1394_start_fcp_listen(raw1394handle_t handle); int raw1394_stop_fcp_listen(raw1394handle_t handle); I haven't tested them so far, but everything compiles. That's good. You can get both subsystem and libraw1394 with the changes from CVS (remember, SourceForge CVS repository). -- Andreas E. Bombe <and...@mu...> http://home.pages.de/~andreas.bombe/ DSA key 0x04880A44 |
From: Eric H. <Eri...@xi...> - 2000-03-15 00:29:17
|
Actually it is the closest device, since when you chain devices together it starts with the farthest node and works its way back to the root node. In other words node 0 works but node 1 doesn't and the root nodeID is 2. Yes both devices will work if they are connected directly to an individual controler, but i wish to chain more than two devices when im finished. Mark Knecht wrote: > Eric, > I assume that the device that is not working is the distant device in the > daisy chain? Does the setup work if both devices are connected directly to > the OHCI controller? (Presuming that you card has at least two ports...) > > Mark > > -----Original Message----- > From: Eric Hammervold [mailto:Eri...@xi...] > Sent: Tuesday, March 14, 2000 2:37 PM > To: lin...@li... > Subject: chained devices > > Im running into a problem with using two devices in a daisy chain > configuration. I can talk with one device but when i try to talk to the > other it ignores the data. These devices are completely identical. Any > ideas on what my problem may be? > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Mark K. <mk...@co...> - 2000-03-14 23:44:23
|
Eric, I assume that the device that is not working is the distant device in the daisy chain? Does the setup work if both devices are connected directly to the OHCI controller? (Presuming that you card has at least two ports...) Mark -----Original Message----- From: Eric Hammervold [mailto:Eri...@xi...] Sent: Tuesday, March 14, 2000 2:37 PM To: lin...@li... Subject: chained devices Im running into a problem with using two devices in a daisy chain configuration. I can talk with one device but when i try to talk to the other it ignores the data. These devices are completely identical. Any ideas on what my problem may be? |
From: Eric H. <Eri...@xi...> - 2000-03-14 22:42:31
|
Im running into a problem with using two devices in a daisy chain configuration. I can talk with one device but when i try to talk to the other it ignores the data. These devices are completely identical. Any ideas on what my problem may be? |
From: Andreas B. <and...@mu...> - 2000-03-12 18:14:04
|
Test message. -- Andreas E. Bombe <and...@mu...> http://home.pages.de/~andreas.bombe/ DSA key 0x04880A44 |