linux1394-devel Mailing List for IEEE 1394 for Linux (Page 530)
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: <fra...@ya...> - 2000-05-23 07:51:30
|
> I have been trying to get your ethernet driver to > work on my machines, > but have had no luck. I can insmod the driver and > do an ifup no problem, > but when I try to do anything on the network between > the two machines the > kernel generates an oops and then panics. > > I have noticed that the ethernet address always > comes up as: > HWaddr 00:00:69:65:65:00 > on both machines. > 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. I have updated the README file of http://www.chez.com/kayle/IEEE_1394/ether_1394.tgz if you need more informations. ----- Franck Bonin ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr |
From: <fir...@se...> - 2000-05-22 18:32:17
|
I have been trying to get your ethernet driver to work on my machines, but have had no luck. I can insmod the driver and do an ifup no problem, but when I try to do anything on the network between the two machines the kernel generates an oops and then panics. I have noticed that the ethernet address always comes up as: HWaddr 00:00:69:65:65:00 on both machines. Unable to handle kernle NULL pointer derefernece at virtual address 00000004 current->tss.cr3 = 00101000, %cr3 = 00101000 *pde = 00000000 Oops: 0002 CPU: 0 EIP: 0010:[<c01594c3>] EFLAGS: 00010247 eax: cf0b92a0 ebx: 00000001 ecx: cf4df3f0 edx: 00000000 esi: cf4df380 edi: d089c440 ebp: c01e9fa0 esp: c01e9f44 ds: 0018 es: 0018 ss: 0018 Pocsess swapper (pid: 0, process nr: 0, stackpage=c01e9000) Stack: c01592d7 cf4df380 d089c440 cf4df380 c01ddfe0 c015935a d089c440 00000001 c020cc84 00000000 c01560ba 00000001 c020cc84 00000000 c01e9fa0 00004201 c01e9fa8 c011adb1 c01e9fa8 c01e8000 c020b4c0 c010b232 c01e8000 00001000 Call Trace: [<c01592d7>] [<d089c440>] [<c015935a>] [<d089c440>] [<c01560ba>] [<c011adb1>] [<c010b232>] [<c010a220>] [<c0107a15>] [<c0106000>] [<c0106000>] [<c01001b1>] Code: 89 4a 04 89 11 c7 00 00 00 00 00 c7 40 04 00 00 00 00 c7 40 Aiee, killing interrupt handler Kernel panic: Attempted to kill the idle task! In swapper task - not syncing Our Machines kernel 2.2.15 Firewire driver CVS May 10 2000 libraw 0.6 Motherboard Supermicro P6DBE Proccessor dual PII 350 RAM 256Meg Firewire card Unibrain FireBoard 400 Ethernet 3 DEC DC21140 (tulip) Video GeForce DDR Judd Tracy jt...@is... On Fri, 19 May 2000, [iso-8859-1] Franck Bonin wrote: > For those who want to play with ethernet on IEEE 1394, > here is my ethernet driver under GPL : > > http://www.chez.com/kayle/IEEE_1394/ether_1394.tgz > > There is also a new version of capture which should > play PAL and > NTSC video, NTSC audio, and detect corrupted video > frames: > > http://www.chez.com/kayle/IEEE_1394/capture_0.1.0.tgz > > ---- > > Franck Bonin > > ___________________________________________________________ > Do You Yahoo!? > Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux1394-devel > |
From: Mark K. <mk...@co...> - 2000-05-22 14:12:42
|
(2ND ATTEMPT - Sunday's e-mail failed due to length of attachments.) =A0 Hi all, =A0=A0 Contained herein is some data I've collected concerning how my = Linux system is acting during a warm boot. Basic status of the system is: =A0 1) Linux PC using CVS code tree for both ieee1394 & libraw1394 2) 1394 support compiled into kernel 3) Five 1394 devices on the bus, Linux PC is the only 400Mb device. (On purpose!) =A0 =A0=A0 When I reboot this PC, sometimes it boots 'friendly', meaning my = other PC, a Windoze box, does not especially react to the fact that the = reboot is happening. Many times, however, that PC reacts noticeably by slowing = down to a crawl for what appears to be 5-10 seconds. Even the mouse on that = system acts badly when the Linux box is rebooting. I think the data in the = attached files shows generally what is going on. =A0 =A0=A0 In all cases, the other four 1394 devices are powered up and = ready to go, and there is no 'intended' bus traffic taking place. No applications = are running. I don't think the camera device is transmitting anything. The = CR-RW & RDK aren't doing anything. =A0 =A0=A0 I'm placing the simple version of the text for you to look at in = the attachment 'e-mail-text.txt' and the more complete version of the boot sequences in 'boot-sequence.txt' so that email line length limiters = don't make it too hard to read. =A0 =A0=A0 In e-mail-text.txt, notice that in the friendly sequence we are = the only 400Mb device, and that we generated the bus reset. However, in the unfriendly sequence, we did not generate the bus reset, but device 0 = did. At the end of the unfriendly sequence in this file you see the = 'unsolicited response packet', which starts off the next set of bus resets and = Self-ID sequences. This goes on for quite awhile, and then eventually calms = down. (See=A0SHORT-boot-sequence.txt) (Notice that the two sequences are = actually quite different much earlier on...) =A0 =A0=A0 I am concerned about whether some of this might be caused by way = I built and installed the new kernel. LILO=A0is possibly not reading the right system.map file for this revision of the kernel. Comments on this are = very welcome. I have multiple kernels installed in lilo.conf, but it does = not seem to me that after a reboot the System.Map link is always pointing = at the one that is currently running, and the line in the message file doesn't = seem to me that it is reading the right one. I may rebuild this system with = a single kernel just to ensure that this is not the issue. =A0 =A0=A0 If anyone has ideas about other experiments I could do, I = welcome those also. =A0 With best regards, Mark |
From: Eric B. <eb...@fr...> - 2000-05-22 06:22:05
|
Hi, I would like to know if someone here succeeded in getting the ieeee1394 drivers working on a powermac (with linuxppc) ? Thank you very much Eric |
From: Erik W. <om...@cs...> - 2000-05-21 21:10:05
|
On Sun, 21 May 2000 aw...@an... wrote: > I've not seen anything in this list (or the PCMCIA project pages) > about PCMCIA 1394 cards. Are any known to be supported/ are there > plans to support them? Is this an issue for PCMCIA, or for 1394 lists- > or both? > > I have a WesternDigital 1394 PCCard, and would like to use it under > Linux. I installed the 1394 kernel patch, but the card isn't > recognized by the card manager. Does anyone have any experience with > this specific card? I've done a lot of work trying to get the 1394 subsystem to do CardBus cards. I can get my OHCI card to recognize and almost self-id, but for some reason interrupts never really make it to the card. I haven't had time to look into this recently, but I'll be doing so within a month, since I'll probably need it. The key is a rewrite of the host management code, since it's very not 2.3 friendly. I need to get my changes applied to the latest code so I can submit a patch, then get the host controller drivers rearranged so they work. Then CardBus should be close to working. Erik Walthinsen <om...@cs...> - Staff Programmer @ OGI Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/ Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/ __ / \ SEUL: Simple End-User Linux - http://www.seul.org/ | | M E G A Helping Linux become THE choice _\ /_ for the home or office user |
From: <aw...@an...> - 2000-05-21 20:58:33
|
I've not seen anything in this list (or the PCMCIA project pages) about PCMCIA 1394 cards. Are any known to be supported/ are there plans to support them? Is this an issue for PCMCIA, or for 1394 lists- or both? I have a WesternDigital 1394 PCCard, and would like to use it under Linux. I installed the 1394 kernel patch, but the card isn't recognized by the card manager. Does anyone have any experience with this specific card? Thanks, Andrew |
From: Mark K. <mk...@co...> - 2000-05-21 18:20:38
|
Hi all, =A0=A0 Contained herein is some data I've collected concerning how my = Linux system is acting during a warm boot. Basic status of the system is: =A0 1) Linux PC using CVS code tree for both ieee1394 & libraw1394 2) 1394 support compiled into kernel 3) Five 1394 devices on the bus, Linux PC is the only 400Mb device. (On purpose!) =A0 =A0=A0 When I reboot this PC, sometimes it boots 'friendly', meaning my = other PC, a Windoze box, does not especially react to the fact that the = reboot is happening. Many times, however, that PC reacts noticeably by slowing = down to a crawl for what appears to be 5-10 seconds. Even the mouse on that = system acts badly when the Linux box is rebooting. I think the data in the = attached files shows generally what is going on. =A0 =A0=A0 In all cases, the other four 1394 devices are powered up and = ready to go, and there is no 'intended' bus traffic taking place. No applications = are running. I don't think the camera device is transmitting anything. The = CR-RW & RDK aren't doing anything. =A0 =A0=A0 I'm placing the simple version of the text for you to look at in = the attachment 'e-mail-text.txt' and the more complete version of the boot sequences in 'boot-sequence.txt' so that email line length limiters = don't make it too hard to read. =A0 =A0=A0 In e-mail-text.txt, notice that in the friendly sequence we are = the only 400Mb device, and that we generated the bus reset. However, in the unfriendly sequence, we did not generate the bus reset, but device 0 = did. At the end of the unfriendly sequence in this file you see the = 'unsolicited response packet', which starts off the next set of bus resets and = Self-ID sequences. This goes on for quite awhile, and then eventually calms = down. (See boot-sequence.txt) (Notice that the two sequences are actually = quite different much earlier on...) =A0 =A0=A0 I am concerned about whether some of this might be caused by way = I built and installed the new kernel. LILO possibly not reading the right = system.map file, or the right module-info file. Comments on this are very welcome. = I have multiple kernels installed in lilo.conf, but it does not seem to = me that after a reboot the System.Map link is always pointing at the one = that is currently running, and the line in the message file doesn't seem to = me that it is reading the right one. I may rebuild this system with a = single kernel just to ensure that this is not the issue. =A0 =A0=A0 If anyone has ideas about other experiments I could do, I = welcome those also. =A0 With best regards, Mark |
From: Erik W. <om...@cs...> - 2000-05-20 20:07:01
|
On 20 May 2000, Gord Wait wrote: > Any chance of making a non MMX version? I'm still on > a non MMX pentium. I suppose non MMX wouldn't be fast enough > to run xdvplay? It's been suggested that libdv be set up with a quality control variable, which could be tuned all the way down to only decode the DC components (as demonstrated by someone else's package, the name escapes me at the moment), which will yield a small thumbnail window (1/8 size both axes), but can be done on just about any machine capable of actually transfering 25Mbps through it. Keeping MMX out of the loop will be a function of how the library is utilized. I've got a prototype of this library style set up in my bitstream code (which will be used in libdv RSN), but libdv is sufficiently different that it'll need a different style (difference: bitstream code is all inlined, so #ifdefs work, but libdv is all library code, so function pointers must be used). Just as a general note, we're aiming right now at a 400MHz PII as our target for non-accellerated playback (i.e. no XFree 4.0 YUV hardware overlays), and we may eventually be able to squeeze it into to a 300MHz box, but don't hold your breath. It's that hard of a problem. Erik Walthinsen <om...@cs...> - Staff Programmer @ OGI Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/ Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/ __ / \ SEUL: Simple End-User Linux - http://www.seul.org/ | | M E G A Helping Linux become THE choice _\ /_ for the home or office user |
From: Gord W. <Gor...@ne...> - 2000-05-20 17:31:20
|
Any chance of making a non MMX version? I'm still on a non MMX pentium. I suppose non MMX wouldn't be fast enough to run xdvplay? Gord Wait Arne Schirmacher <ar...@sc...> wrote: > I have made an own home page for the xdvplay program: > > http://www.schirmacher.de/arne/xdvplay/index_english.html > > There is also a new xdvplay version. It is adapted to the latest version of > libdv. The tar file now contains a copy of a known working copy of libdv, > because the libdv changes rapidly and several users could not compile xdvplay.c > with the latest and greatest libdv version. It has however additional > instructions where and how to get the very latest version. > > http://www.schirmacher.de/arne/xdvplay/xdvplay_latest.tar.gz > > We should really have libdv in library format, as its name suggests... is > anybody listening ? :-) > > I am also working on a patch to the xanim video player program to use the libdv > code. Stay tuned. > > > Arne > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux1394-devel ____________________________________________________________________ Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com. |
From: Manfred W. <e95...@st...> - 2000-05-20 16:11:23
|
Mark Knecht wrote: > I think one important point you make is the compile option - kernel vs. > modules. I am compiled into the kernel and that means the loading of the > driver stack is earlier. I could certainly take it out, but I think in the > end it is not practical to have end-user types doing insmod's. I know, > 'cause I'm an in user type and I don't know how to do it!! I think you misunderstood me. I wrote that I also compiled it into the kernel and _not_ into modules. I did this, because I did not want to bother around with that insmod's. But because of the mentioned stablity problems I consider to put it into models and only load them, when I really need them (or to plug off the 1394 cable and only plug in on demand...). But I think, that that makes not much difference, it only affects the timing, when the driver is loaded. > I may make a version of the kernel with module based loading this > weekend. Could you send back the instructions for doing the insmod steps so > that I get it right? I think, you will get two modules, one for the low-level-driver (pciylynx.o or ohci.o or something like that) and one for the higher-level (hardware-independent) subsystem functionality (maybe it's called ieee1394.o?, look into /lib/modules) and you will have to insmod both (I think first the lowlevel-driver, try it!). > I agree that some of the stability problem seems more apparent when I > build larger topologies. I intend to look into this more later. And we also see, that we are still far away from putting it into stable kernel releases (2.2 or 2.4). But as cold comfort: That is also true for the windows drivers; the only difference is, that here (on linux) it is explicitly marked as experimental code, whereas MS claims that they have stable code and sells beta-software as final releases... Manfred |
From: Erik W. <om...@cs...> - 2000-05-20 05:00:08
|
On Sat, 20 May 2000, Arne Schirmacher wrote: > We should really have libdv in library format, as its name suggests... is > anybody listening ? :-) Yeah, it's at the very top of my list of things to do. This last week was pretty shot while I attended the International Electronic Cinema Festival, where the focus was mostly HD and not DV, but still very interesting. Toy Story 2 projected in pure digital on a large screen, well, it just doesn't get any better than that. ;-) I'll be starting on making libdv an actual library tomorrow, hopefully I'll get it done tomorrow too ;-) Erik Walthinsen <om...@cs...> - Staff Programmer @ OGI Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/ Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/ __ / \ SEUL: Simple End-User Linux - http://www.seul.org/ | | M E G A Helping Linux become THE choice _\ /_ for the home or office user |
From: Arne S. <ar...@sc...> - 2000-05-20 04:55:58
|
I have made an own home page for the xdvplay program: http://www.schirmacher.de/arne/xdvplay/index_english.html There is also a new xdvplay version. It is adapted to the latest version of libdv. The tar file now contains a copy of a known working copy of libdv, because the libdv changes rapidly and several users could not compile xdvplay.c with the latest and greatest libdv version. It has however additional instructions where and how to get the very latest version. http://www.schirmacher.de/arne/xdvplay/xdvplay_latest.tar.gz We should really have libdv in library format, as its name suggests... is anybody listening ? :-) I am also working on a patch to the xanim video player program to use the libdv code. Stay tuned. Arne |
From: Mark K. <mk...@co...> - 2000-05-19 22:50:59
|
That did it Andreas. thanks -----Original Message----- From: Andreas Bombe [mailto:and...@mu...] Sent: Friday, May 19, 2000 3:09 PM To: Mark Knecht Cc: Linux1394 Developer's Reflector (E-mail) Subject: Re: Problems building from CVS tree On Fri, May 19, 2000 at 10:29:33AM -0700, Mark Knecht wrote: > Hi, > First time attempting a build with code downloaded from the CVS tree > instead of the patch. [...] > ieee1394_types.h:37: `dev' undeclared (first use in this function) > ieee1394_types.h:37: (Each undeclared identifier is reported only once > ieee1394_types.h:37: for each function it appears in.) Sorry, my fault. Fixed, update from CVS and try again. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: James G. <jamesg@Filanet.com> - 2000-05-19 22:46:11
|
Hi, Many 1394 cards come up with LPS on (and send the link_active bit in their self-id), and return ack_pending to async requests. Both the Adaptec NT4.0 driver and the MS driver stacks attempt to read the config rom during enumeration. Since the link returns ack_pending, these drivers must wait for a split-transaction timeout, and then they retry several times (in case it is a slow device they're talking to) before giving up. So, it can take quite a while in this case for the enumerating driver to "figure out" that the Link (and software) is not really there yet. Anyway, sounds like this is what you're seeing. Actually, it sounds like there is a bug in the Adaptec NT 4.0 driver, since OHCI based cards should come up with LPS off (Adaptec driver probably doesn't check link_active bit before trying to enumerate a node). I guess I would recommend Win2K and an OHCI card for testing with other PCs. Adaptec is not actively supporting their 1394 cards or drivers anymore. Cheers, --James >From: Mark Knecht <mk...@co...> >To: "Linux1394 Developer's Reflector (E-mail)" ><lin...@li...> >Subject: RE: Linux 1394 somewhat unfriendly during boot? >Date: Fri, 19 May 2000 09:56:53 -0700 >charset="iso-8859-1" > >Matt, > >NT 4.0 >Adaptec Driver from the retail pack, Microsoft doesn't support 1394 under NT >4.0 to the best of my knowledge. Not until Windows 2K >I haven't bothered to look on Adaptec's site for anything newer yet. I'll >poke around this afternoon and see what I find. > >Interesting idea that it is the Windows box and not the Linux box causing >the problem. I'll see if I can figure out how to determine this... > >Thanks, >Mark |
From: Mark K. <mk...@co...> - 2000-05-19 22:22:28
|
Manfred, Thanks for the info. There's some good stuff there. I think one important point you make is the compile option - kernel vs. modules. I am compiled into the kernel and that means the loading of the driver stack is earlier. I could certainly take it out, but I think in the end it is not practical to have end-user types doing insmod's. I know, 'cause I'm an in user type and I don't know how to do it!! I may make a version of the kernel with module based loading this weekend. Could you send back the instructions for doing the insmod steps so that I get it right? I agree that some of the stability problem seems more apparent when I build larger topologies. I intend to look into this more later. I am also seeing inconsistent identification of devices. Sometimes the GUID's show up, sometimes they don't. I'd like to get my hands on a real analyzer (3A or something) but they are too expensive for play. I understood that there used to be some TI software for doing this with PCI-Lynx. Is anyone in possession of that? More later, I'm sure. Thanks, Mark -----Original Message----- From: Manfred Weihs [mailto:e95...@st...] Sent: Friday, May 19, 2000 11:12 AM To: lin...@li... Subject: Re: Linux 1394 somewhat unfriendly during boot? Mark Knecht wrote: > This seems like the Linux 1394 system may be pumping a lot of either packets > onto the bus, or doing a lot of bus resets. I also observed, that when booting my linux PC (and since I compiled 1394 into the kernel, not into modules, the subsystem is loaded during bootup) several bus resets occur. I do not know if this is bad or unfriendly (the design of 1394 allows bus resets anytime, so it should not hurt, if there are several bus resets), but I think one bus reset should be enough. I more frequently observed problems in the other direction, that activities of other nodes caused my linux to crash. For example we have 1394-evaluation-boards from Vitana in our 1394-network, and if we press the reset-button on this boards, my Linux pc sometimes dies (either completly hangs up, so that I am not even able to ping it, or it starts a reboot, or during reboot [mostly during fscheck since this takes some time] gets a kernel panic). BTW: The Win boxes also die sometimes, but my linux box does so more frequently. I am sorry, that I was not yet able to find out, what conditions must exactly be fulfilled to cause such a crash, so I cannot always reproduce it (that is the reason why I did not yet post a bug report to the list); but it seems that the instability grows with the number of active nodes in the network. I am not sure, if this is caused by a problem of the hardware (Unibrain card) or the lowlevel driver (pcilynx) or by the higher subsystem layers. But I think that it is rather a software than a hardware problem, because I yesterday tried to press the reset-button of that Vitana-board many times during bootup and linux hang up _after_ the 1394-driver was loaded. Manfred Weihs _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Andreas B. <and...@mu...> - 2000-05-19 22:11:54
|
On Fri, May 19, 2000 at 10:29:33AM -0700, Mark Knecht wrote: > Hi, > First time attempting a build with code downloaded from the CVS tree > instead of the patch. [...] > ieee1394_types.h:37: `dev' undeclared (first use in this function) > ieee1394_types.h:37: (Each undeclared identifier is reported only once > ieee1394_types.h:37: for each function it appears in.) Sorry, my fault. Fixed, update from CVS and try again. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Manfred W. <e95...@st...> - 2000-05-19 21:33:41
|
Mark Knecht wrote: > This seems like the Linux 1394 system may be pumping a lot of either packets > onto the bus, or doing a lot of bus resets. I also observed, that when booting my linux PC (and since I compiled 1394 into the kernel, not into modules, the subsystem is loaded during bootup) several bus resets occur. I do not know if this is bad or unfriendly (the design of 1394 allows bus resets anytime, so it should not hurt, if there are several bus resets), but I think one bus reset should be enough. I more frequently observed problems in the other direction, that activities of other nodes caused my linux to crash. For example we have 1394-evaluation-boards from Vitana in our 1394-network, and if we press the reset-button on this boards, my Linux pc sometimes dies (either completly hangs up, so that I am not even able to ping it, or it starts a reboot, or during reboot [mostly during fscheck since this takes some time] gets a kernel panic). BTW: The Win boxes also die sometimes, but my linux box does so more frequently. I am sorry, that I was not yet able to find out, what conditions must exactly be fulfilled to cause such a crash, so I cannot always reproduce it (that is the reason why I did not yet post a bug report to the list); but it seems that the instability grows with the number of active nodes in the network. I am not sure, if this is caused by a problem of the hardware (Unibrain card) or the lowlevel driver (pcilynx) or by the higher subsystem layers. But I think that it is rather a software than a hardware problem, because I yesterday tried to press the reset-button of that Vitana-board many times during bootup and linux hang up _after_ the 1394-driver was loaded. Manfred Weihs |
From: Mark K. <mk...@co...> - 2000-05-19 17:30:49
|
Hi, First time attempting a build with code downloaded from the CVS tree instead of the patch. 1) Downloaded ieee1394 as per instructions on the web page. Everything seemed fine. 2) Moved existing ieee1394 directory out of the kernel tree and replaced it with the ieee1394 directory created by the CVS download. (This was guess as there were no instructions I found...) 3) Ran make xconfig 4) Ran make clean dep bzImage modules modules_install Got this result at the end of the build: make -C ieee1394 make[2]: Entering directory `/usr/src/1394-linux-2.2.15/drivers/ieee1394' make all_targets make[3]: Entering directory `/usr/src/1394-linux-2.2.15/drivers/ieee1394' gcc -D__KERNEL__ -I/usr/src/1394-linux-2.2.15/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586 -DEXPORT_SYMTAB -c ieee1394_syms.c ieee1394_types.h: In function `pci_enable_device': In file included from ieee1394_syms.c:12: ieee1394_types.h:37: `dev' undeclared (first use in this function) ieee1394_types.h:37: (Each undeclared identifier is reported only once ieee1394_types.h:37: for each function it appears in.) make[3]: *** [ieee1394_syms.o] Error 1 make[3]: Leaving directory `/usr/src/1394-linux-2.2.15/drivers/ieee1394' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/1394-linux-2.2.15/drivers/ieee1394' make[1]: *** [_subdir_ieee1394] Error 2 make[1]: Leaving directory `/usr/src/1394-linux-2.2.15/drivers' make: *** [_dir_drivers] Error 2 [root@bambi linux]# |
From: Mark K. <mk...@co...> - 2000-05-19 16:58:10
|
Matt, NT 4.0 Adaptec Driver from the retail pack, Microsoft doesn't support 1394 under NT 4.0 to the best of my knowledge. Not until Windows 2K I haven't bothered to look on Adaptec's site for anything newer yet. I'll poke around this afternoon and see what I find. Interesting idea that it is the Windows box and not the Linux box causing the problem. I'll see if I can figure out how to determine this... Thanks, Mark -----Original Message----- From: Matt Pujol [mailto:ma...@ls...] Sent: Friday, May 19, 2000 9:44 AM To: Mark Knecht Cc: Linux1394 Developer's Reflector (E-mail) Subject: Re: Linux 1394 somewhat unfriendly during boot? What version of NT are you running? In the NT box, is it a Microsoft-provided 1394 driver or an OEM driver? Some of the early (pre-Win98SE) 1394 stacks had trouble with devices that didn't enumerate properly. That could be what's happening, the LPS bit is set in your SelfID, but the Link isn't responding to ConfigROM reads. Hence, Windows is completely baffled and continues to hammer on the Linux box until it comes up. Regards, Matt Mark Knecht wrote: Has anyone else seen this problem? I have a 1394 topology with two PCs and a number of other peripherals. One PC is the Linux box, the other is a Windows NT box with an Adaptec 1394 card in it. If the Linux box is powered off and the Windows box is up and running normally, and then I power on the Linux box, during the boot process on Linux the Windows box is slowed to a crawl. The mouse will barely move, everything is very slow. If I unplug the 1394 cable from either box (leaving the rest of my topology intact, the Windows box speeds up again. This seems like the Linux 1394 system may be pumping a lot of either packets onto the bus, or doing a lot of bus resets. I don't have a 3A here, so I can't really look at what is going on. Does anyone know of any software for the Adaptec cards that will allow me to just capture packets/bus operation? _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel -- /*********************** Matt Pujol Product Marketing Manager 1394 and USB CoreWare technologies LSI Logic 2001 Danfield Court Fort Collins, Co 80525 970-206-5816 mat...@ls... ***********************/ |
From: Matt P. <ma...@ls...> - 2000-05-19 16:45:33
|
What version of NT are you running? In the NT box, is it a Microsoft-provided 1394 driver or an OEM driver? Some of the early (pre-Win98SE) 1394 stacks had trouble with devices that didn't enumerate properly. That could be what's happening, the LPS bit is set in your SelfID, but the Link isn't responding to ConfigROM reads. Hence, Windows is completely baffled and continues to hammer on the Linux box until it comes up. Regards, Matt Mark Knecht wrote: > Has anyone else seen this problem? > > I have a 1394 topology with two PCs and a number of other peripherals. One > PC is the Linux box, the other is a Windows NT box with an Adaptec 1394 card > in it. If the Linux box is powered off and the Windows box is up and running > normally, and then I power on the Linux box, during the boot process on > Linux the Windows box is slowed to a crawl. The mouse will barely move, > everything is very slow. If I unplug the 1394 cable from either box (leaving > the rest of my topology intact, the Windows box speeds up again. > > This seems like the Linux 1394 system may be pumping a lot of either packets > onto the bus, or doing a lot of bus resets. I don't have a 3A here, so I > can't really look at what is going on. > > Does anyone know of any software for the Adaptec cards that will allow me to > just capture packets/bus operation? > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux1394-devel -- /*********************** Matt Pujol Product Marketing Manager 1394 and USB CoreWare technologies LSI Logic 2001 Danfield Court Fort Collins, Co 80525 970-206-5816 mat...@ls... ***********************/ |
From: Mark K. <mk...@co...> - 2000-05-19 14:11:36
|
Has anyone else seen this problem? I have a 1394 topology with two PCs and a number of other peripherals. One PC is the Linux box, the other is a Windows NT box with an Adaptec 1394 card in it. If the Linux box is powered off and the Windows box is up and running normally, and then I power on the Linux box, during the boot process on Linux the Windows box is slowed to a crawl. The mouse will barely move, everything is very slow. If I unplug the 1394 cable from either box (leaving the rest of my topology intact, the Windows box speeds up again. This seems like the Linux 1394 system may be pumping a lot of either packets onto the bus, or doing a lot of bus resets. I don't have a 3A here, so I can't really look at what is going on. Does anyone know of any software for the Adaptec cards that will allow me to just capture packets/bus operation? |
From: <fra...@ya...> - 2000-05-19 13:09:07
|
For those who want to play with ethernet on IEEE 1394, here is my ethernet driver under GPL : http://www.chez.com/kayle/IEEE_1394/ether_1394.tgz There is also a new version of capture which should play PAL and NTSC video, NTSC audio, and detect corrupted video frames: http://www.chez.com/kayle/IEEE_1394/capture_0.1.0.tgz ---- Franck Bonin ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr |
From: Andreas B. <and...@mu...> - 2000-05-19 12:54:13
|
On Wed, May 17, 2000 at 12:30:59PM +0200, Manfred Weihs wrote: > 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. Only the bus manager is _required_ to do so, but nothing stops other nodes from providing a topology map. Our subsystem always does. You can read the local topology map and assume the data is valid. Same for speed map, if you want it. libraw should provide an easier way to find out which nodes are the iso and bus managers. This is determined at bus reset time in the kernel anyway (except for bus manager which isn't done yet), so that can very well be exported. I'll look into that for the next release. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Bruce M. <br...@tr...> - 2000-05-19 02:35:53
|
Hey Scott, I really didn't do anything special to get my camera working. I simply made a ieee1394 kernel, made and installed libraw1394 (see my posts about a rpm version of this) and got gscanbus. Gscanbus saw it, I could send it avc commands and it all worked quite spendidly. I then experimented using grabdv and that worked fine. My firewire hardware is a cheapo VIA base solution that cost me $45 at www.compgeeks.com. Its a OHCI card and it works fine. My other card, Adaptec 5880, that I got with my Miro DV200 didn't work and I was disinclined to spend lots of time (and I did spend time) trying to get it to work especially in the face of the bargain card. I am still trying to get timecodes from the tape. I would really like for one of the resident experts to look over my code to see if there is any glaring flaw. I will email this list with a suitable email with code snippets, etc, etc and see if anyone can help. Please feel free to email me for any other specifics, Bruce. PS. The test machine is a VIA MVP3 + K6/500 + 256Mb RAM running Mandrake Linux 7.x - really nothing out of the ordinary (albeit non-pure intel). On Thu, 18 May 2000, Scott Nichols wrote: > >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 > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux1394-devel > |
From: Prabhakar G. <pra...@wi...> - 2000-05-18 22:58:54
|
Is there any document available which might help me understand GNU/Linux IEEE-1394 Subsystem code. TIA, Prabhakar |