FreeBSD 6.2 AMD64 nforce4 ultra VIA VT6307 firewire controller (onboard) NEC uPD72871/2 firewire controller (on PCI card) Canon DV camcorder fwohci0: <VIA Fire II (VT6306)> port 0xa800-0xa87f mem 0xfdffe000-0xfdffe7ff irq 11 at device 6.0 on pci1 fwohci1: <NEC uPD72871/2> mem 0xfdeff000-0xfdefffff irq 12 at device 8.0 on pci2 Using the VIA controller, "fwcontrol -R" works okay. But "fwcontrol -S" does not work correctly. It plays for roughly 1.5 seconds, then both the audio and video drop out for a moment. This repeats over and over at regular intervals. No error messages appear in dmesg or syslog. Perhaps a flow control or buffering problem causing the camcorder to run out of data? Using the NEC firewire controller, it acts the same as the VIA controller if the camcorder is powered up with FreeBSD already running. If I reboot FreeBSD, and power up the camcorder while FreeBSD is not running (e.g. firmware or boot loader), then "fwcontrol -S" works fine. This workaround does not work with the VIA controller. Leaving the camcorder on and rebooting FreeBSD does not change anything, If it was working it remains working, if it was not working it remains not working. "fwcontrol -r" does not help. There must be something different sent to the camera when "hot plugging" (actually just powering up, not plugging/unplugging) verses booting.
Responsible Changed From-To: freebsd-bugs->freebsd-firewire Firewire related.
State Changed From-To: open->feedback I increased tx/rx buffer size in rev. 1.7 and 1.5.12.2 of src/usr.sbin/fwcontrol/fwdv.c. I hope this fixes your problem.
[ previous reply didn't make it into the PR system, trying again ] In message <200710300119.l9U1Jsv8040070@freefall.freebsd.org>, simokawa@FreeBSD.org writes: > Synopsis: [firewire] dropouts when playing DV on firewire > > State-Changed-From-To: open->feedback > State-Changed-By: simokawa > State-Changed-When: Tue Oct 30 01:17:44 UTC 2007 > State-Changed-Why: > I increased tx/rx buffer size in rev. 1.7 and 1.5.12.2 of > src/usr.sbin/fwcontrol/fwdv.c. I hope this fixes your problem. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=113785 -#define NCHUNK 8 +#define NCHUNK 64 I tried this, it didn't help. I also tried cranking it up to 256, which still didn't help. :-( Given that the NEC controller has the problem only when "hot powered-up", I wonder if it is an initialization problem. Is there a way to log what FreeBSD sends to the camcorder, similar to tcpdump(1) ? Comparing what FreeBSD sends if it detects the camcorder at boot time with what it sends when the camcorder is powered up later might allow fixing the having-to-reboot problem. Perhaps the VIA controller always sends the bad initialization? The compiler whined: fwcontrol.c:611: warning: control reaches end of non-void function fwdv.c:93: warning: no previous prototype for 'dvrecv' fwdv.c:248: warning: no previous prototype for 'dvsend' At least the compiler warnings are easily fixed: diff -u -r1.1 fwcontrol.c --- fwcontrol.c 2007/10/30 15:32:15 1.1 +++ fwcontrol.c 2007/10/30 15:33:10 @@ -58,7 +58,7 @@ extern int dvrecv(int, char *, char, int); extern int dvsend(int, char *, char, int); -int sysctl_set_int(const char *, int); +void sysctl_set_int(const char *, int); static void usage(void) @@ -603,7 +603,7 @@ } } -int +void sysctl_set_int(const char *name, int val) { if (sysctlbyname(name, NULL, NULL, &val, sizeof(int)) < 0) diff -u -r1.1 fwdv.c --- fwdv.c 2007/10/30 02:50:42 1.1 +++ fwdv.c 2007/10/30 15:45:42 @@ -88,6 +88,10 @@ #define MAXBLOCKS (300) #define CYCLE_FRAC 0xc00 +/* prototypes */ +int dvrecv(int, char *, char, int); +int dvsend(int, char *, char, int); + int dvrecv(int d, char *filename, char ich, int count) {
> There is no initialization packet to send streams; By initialization, I meant whatever conversation FreeBSD and the camcorder have once they are both up. > however, > it might be a problem who is the cycle/bus/IR manager. > Can you see some difference of the output of the fwcontrol(8) and demsg(8) > in node-id, cycle master and etc. between success and failed cases? Yes, we have a couple of new clues: When FreeBSD says "CYCLEMASTER mode" it does not work. When FreeBSD says "non CYCLEMASTER mode" it works. Also: The controller that works (if booted in correct order): just bsd: # fwcontrol -u 1 -t crc_len: 3 generation:2 node_count:1 sid_count:1 id link gap_cnt speed delay cIRM power port0 port1 port2 ini more 00 1 5 S400 0 1 -9W - - 1 0 now power up camcorder (does not work): # fwcontrol -u 1 -t crc_len: 4 generation:3 node_count:2 sid_count:2 id link gap_cnt speed delay cIRM power port0 port1 port2 ini more 00 1 63 S100 0 1 0W - P 1 0 01 1 5 S400 0 1 -9W - C 0 0 Looks like the S400 & non-zero power device (BSD box) changed id from 00 to 01? after booting camcorder and FreeBSD in correct order (works): # fwcontrol -u 1 -t crc_len: 4 generation:1 node_count:2 sid_count:2 id link gap_cnt speed delay cIRM power port0 port1 port2 ini more 00 1 63 S400 0 1 -9W - P 1 0 01 1 63 S100 0 1 0W - C 0 0 Note that the BSD box is id 00. The controller that never works: # fwcontrol -u 0 -t crc_len: 4 generation:2 node_count:2 sid_count:2 id link gap_cnt speed delay cIRM power port0 port1 port2 ini more 00 1 5 S100 0 1 0W - P 0 0 01 1 5 S400 0 1 15W C - 1 0 The BSD box is id 01. Perhaps the "C" showing up under port0 instead of port1 is significant? So: if the BSD box is id 00, camcorder is id 01 -> works if the BSD box is id 01, camcorder is id 00 -> does not work > Thanks for a fix for the compiler warning. You're welcome.
State Changed From-To: feedback->open Note that feedback was received some time ago.
Sorry for the late response. Yes, it is possible in some way. Usually, the root node becomes the cycle master and the root node is the node which has the maximum node id. Try the patch I have just committed to -current. ------ simokawa 2008-03-05 01:30:49 UTC FreeBSD src repository Modified files: usr.sbin/fwcontrol fwcontrol.8 fwcontrol.c Log: - add '-f' option to force root node. - fix byte order in read_write_quad() - show hostnames in the list - fix typo in manpage MFC after: 1 week Revision Changes Path 1.22 +6 -1 src/usr.sbin/fwcontrol/fwcontrol.8 http://cvsweb.FreeBSD.org/src/usr.sbin/fwcontrol/fwcontrol.8.diff?r1=1.21&r2=1.22&f=h 1.24 +17 -7 src/usr.sbin/fwcontrol/fwcontrol.c http://cvsweb.FreeBSD.org/src/usr.sbin/fwcontrol/fwcontrol.c.diff?r1=1.23&r2=1.24&f=h ------- Suppose your camcorder has node id 0 and your FreeBSD box has node id 1, run the followins commands. # fwcontrol -f 0 # fwcontrol -r Then, your camcorder should turn to be the cycle master. At Thu, 10 Jan 2008 11:39:00 +0000, Dieter wrote: > > Re: kern/113785 > > Could "CYCLEMASTER mode" vs. "non CYCLEMASTER mode" be > the source of my firewire problems? > > Is it possible to force FreeBSD to be in "non CYCLEMASTER mode" ? > > Thanks. > > ------- Forwarded Message > > > > There is no initialization packet to send streams; > > > > By initialization, I meant whatever conversation FreeBSD and the > > camcorder have once they are both up. > > > > > however, > > > it might be a problem who is the cycle/bus/IR manager. > > > Can you see some difference of the output of the fwcontrol(8) and demsg(8) > > > in node-id, cycle master and etc. between success and failed cases? > > > > Yes, we have a couple of new clues: > > > > When FreeBSD says "CYCLEMASTER mode" it does not work. > > When FreeBSD says "non CYCLEMASTER mode" it works. > > > > Also: > > > > The controller that works (if booted in correct order): > > > > just bsd: > > # fwcontrol -u 1 -t > > crc_len: 3 generation:2 node_count:1 sid_count:1 > > id link gap_cnt speed delay cIRM power port0 port1 port2 ini more > > 00 1 5 S400 0 1 -9W - - 1 0 > > > > now power up camcorder (does not work): > > > > # fwcontrol -u 1 -t > > crc_len: 4 generation:3 node_count:2 sid_count:2 > > id link gap_cnt speed delay cIRM power port0 port1 port2 ini more > > 00 1 63 S100 0 1 0W - P 1 0 > > 01 1 5 S400 0 1 -9W - C 0 0 > > > > Looks like the S400 & non-zero power device (BSD box) changed id from 00 to 01? > > > > after booting camcorder and FreeBSD in correct order (works): > > > > # fwcontrol -u 1 -t > > crc_len: 4 generation:1 node_count:2 sid_count:2 > > id link gap_cnt speed delay cIRM power port0 port1 port2 ini more > > 00 1 63 S400 0 1 -9W - P 1 0 > > 01 1 63 S100 0 1 0W - C 0 0 > > > > Note that the BSD box is id 00. > > > > The controller that never works: > > > > # fwcontrol -u 0 -t > > crc_len: 4 generation:2 node_count:2 sid_count:2 > > id link gap_cnt speed delay cIRM power port0 port1 port2 ini more > > 00 1 5 S100 0 1 0W - P 0 0 > > 01 1 5 S400 0 1 15W C - 1 0 > > > > The BSD box is id 01. > > Perhaps the "C" showing up under port0 instead of port1 is significant? > > > > So: if the BSD box is id 00, camcorder is id 01 -> works > > if the BSD box is id 01, camcorder is id 00 -> does not work > > > > > Thanks for a fix for the compiler warning. > > > > You're welcome. > > ------- End of Forwarded Message > > _______________________________________________ > freebsd-firewire@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-firewire > To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@freebsd.org" > /\ Hidetoshi Shimokawa \/ simokawa@ieee.org
Sorry for the late response. Yes, it is possible in some way. Usually, the root node becomes the cycle master and the root node is the node which has the maximum node id. Try the patch I have just committed to -current. ------ simokawa 2008-03-05 01:30:49 UTC FreeBSD src repository Modified files: usr.sbin/fwcontrol fwcontrol.8 fwcontrol.c Log: - add '-f' option to force root node. - fix byte order in read_write_quad() - show hostnames in the list - fix typo in manpage MFC after: 1 week Revision Changes Path 1.22 +6 -1 src/usr.sbin/fwcontrol/fwcontrol.8 http://cvsweb.FreeBSD.org/src/usr.sbin/fwcontrol/fwcontrol.8.diff?r1=1.21&r2=1.22&f=h 1.24 +17 -7 src/usr.sbin/fwcontrol/fwcontrol.c http://cvsweb.FreeBSD.org/src/usr.sbin/fwcontrol/fwcontrol.c.diff?r1=1.23&r2=1.24&f=h ------- Suppose your camcorder has node id 0 and your FreeBSD box has node id 1, run the followins commands. # fwcontrol -f 0 # fwcontrol -r Then, your camcorder should turn to be the cycle master. At Thu, 10 Jan 2008 11:39:00 +0000, Dieter wrote: > > Re: kern/113785 > > Could "CYCLEMASTER mode" vs. "non CYCLEMASTER mode" be > the source of my firewire problems? > > Is it possible to force FreeBSD to be in "non CYCLEMASTER mode" ? > > Thanks. > > ------- Forwarded Message > > > > There is no initialization packet to send streams; > > > > By initialization, I meant whatever conversation FreeBSD and the > > camcorder have once they are both up. > > > > > however, > > > it might be a problem who is the cycle/bus/IR manager. > > > Can you see some difference of the output of the fwcontrol(8) and demsg(8) > > > in node-id, cycle master and etc. between success and failed cases? > > > > Yes, we have a couple of new clues: > > > > When FreeBSD says "CYCLEMASTER mode" it does not work. > > When FreeBSD says "non CYCLEMASTER mode" it works. > > > > Also: > > > > The controller that works (if booted in correct order): > > > > just bsd: > > # fwcontrol -u 1 -t > > crc_len: 3 generation:2 node_count:1 sid_count:1 > > id link gap_cnt speed delay cIRM power port0 port1 port2 ini more > > 00 1 5 S400 0 1 -9W - - 1 0 > > > > now power up camcorder (does not work): > > > > # fwcontrol -u 1 -t > > crc_len: 4 generation:3 node_count:2 sid_count:2 > > id link gap_cnt speed delay cIRM power port0 port1 port2 ini more > > 00 1 63 S100 0 1 0W - P 1 0 > > 01 1 5 S400 0 1 -9W - C 0 0 > > > > Looks like the S400 & non-zero power device (BSD box) changed id from 00 to 01? > > > > after booting camcorder and FreeBSD in correct order (works): > > > > # fwcontrol -u 1 -t > > crc_len: 4 generation:1 node_count:2 sid_count:2 > > id link gap_cnt speed delay cIRM power port0 port1 port2 ini more > > 00 1 63 S400 0 1 -9W - P 1 0 > > 01 1 63 S100 0 1 0W - C 0 0 > > > > Note that the BSD box is id 00. > > > > The controller that never works: > > > > # fwcontrol -u 0 -t > > crc_len: 4 generation:2 node_count:2 sid_count:2 > > id link gap_cnt speed delay cIRM power port0 port1 port2 ini more > > 00 1 5 S100 0 1 0W - P 0 0 > > 01 1 5 S400 0 1 15W C - 1 0 > > > > The BSD box is id 01. > > Perhaps the "C" showing up under port0 instead of port1 is significant? > > > > So: if the BSD box is id 00, camcorder is id 01 -> works > > if the BSD box is id 01, camcorder is id 00 -> does not work > > > > > Thanks for a fix for the compiler warning. > > > > You're welcome. > > ------- End of Forwarded Message > > _______________________________________________ > freebsd-firewire@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-firewire > To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@freebsd.org" > /\ Hidetoshi Shimokawa \/ simokawa@ieee.org _______________________________________________ freebsd-firewire@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-firewire To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@freebsd.org"
[ note I am still running 6.2 since 7.0 is taking forever to download ] > Suppose your camcorder has node id 0 and your FreeBSD box has node id 1, > run the followins commands. > # fwcontrol -f 0 > # fwcontrol -r > Then, your camcorder should turn to be the cycle master. This works for the NEC controller. THANK YOU !!! However, it does not work for the VIA 6307 controller. :-( FreeBSD remains in CYCLEMASTER mode. I tried it with and without "-u 0" ( VIA is bus 0 NEC is bus 1). I tried rebooting. Nothing helps. #!/bin/bash # # Fix firewire cyclemaster problem # -u 0 is for the onboard firewire VIA controller # echo Before cyclemaster fix /usr/src/usr.sbin/fwcontrol/fwcontrol -u 0 -t echo dmesg | tail -15 echo /usr/src/usr.sbin/fwcontrol/fwcontrol -u 0 -f 0 echo /usr/src/usr.sbin/fwcontrol/fwcontrol -u 0 -r echo After cyclemaster fix /usr/src/usr.sbin/fwcontrol/fwcontrol -u 0 -t echo dmesg | tail -15 Before cyclemaster fix crc_len: 4 generation:11 node_count:2 sid_count:2 id link gap_cnt speed delay cIRM power port0 port1 port2 ini more 00 1 63 S100 0 1 0W - P 1 0 01 1 5 S400 0 1 15W - C 0 0 firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me) firewire0: bus manager 1 (me) fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc1, gen=9, CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me) firewire0: bus manager 1 (me) fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=10, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) fwohci0: BUS reset fwohci0: node_id=0xc800ffc1, gen=11, CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me) firewire0: bus manager 1 (me) send phy_config root_node=0 gap_count=-1 After cyclemaster fix crc_len: 4 generation:12 node_count:2 sid_count:2 id link gap_cnt speed delay cIRM power port0 port1 port2 ini more 00 1 5 S100 0 1 0W - P 0 0 01 1 5 S400 0 1 15W - C 1 0 firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me) firewire0: bus manager 1 (me) fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=10, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) fwohci0: BUS reset fwohci0: node_id=0xc800ffc1, gen=11, CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me) firewire0: bus manager 1 (me) fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc1, gen=12, CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me) firewire0: bus manager 1 (me)
New info: I needed to return the NEC firewire controller to the machine it was borrowed from. Bought a new card with NEC chip to replace it. Differences: Old: <NEC uPD72871/2> mem 0xfdeff000-0xfdefffff irq 10 at device 8.0 on pci2 OHCI version 1.0 (ROM=1) Phy 1394a available S400, 2 ports. Link S400, max_rec 1024 bytes. New: <NEC uPD72874> mem 0xfdffd000-0xfdffdfff irq 19 at device 8.0 on pci1 OHCI version 1.10 (ROM=1) Phy 1394a available S400, 3 ports. Link S400, max_rec 2048 bytes. Additional difference is that old card is combo firewire and usb, new card is just firewire. With the old card, I had to get it into non CYCLEMASTER mode, but with the new card it works fine in CYCLEMASTER mode. So it appears that CYCLEMASTER mode vs non CYCLEMASTER mode isn't the problem. without camcorder: fwcontrol -u 1 -t crc_len: 6 generation:45 node_count:4 sid_count:4 id link gap_cnt speed delay cIRM power port0 port1 port2 ini more 00 Â Â 0 Â Â Â 10 Â S400 Â Â 0 Â Â 0W Â Â P Â Â - Â Â Â Â 1 Â Â 0 01 Â Â 1 Â Â Â 10 Â S400 Â Â 0 Â Â 0W Â Â P Â Â C Â Â Â Â 0 Â Â 0 02 Â Â 0 Â Â Â 10 Â S400 Â Â 0 Â Â 0W Â Â P Â Â - Â Â C Â 1 Â Â 0 03 Â Â 1 Â Â Â 10 Â S400 Â Â 1 Â -1W Â Â - Â Â C Â Â - Â 0 Â Â 0 (The other three lines must be the three repeaters.) power up camcorder: fwohci1: fwohci_intr_core: node_id=0x00000004, SelfID Count=46, CYCLEMASTER mode firewire1: 5 nodes, maxhop <= 4 cable IRM irm(4) Â (me) firewire1: bus manager 4 crc_len: 7 generation:46 node_count:5 sid_count:5 id link gap_cnt speed delay cIRM power port0 port1 port2 ini more 00 Â Â 1 Â Â Â 63 Â S100 Â Â 1 Â Â 0W Â Â - Â Â P Â Â Â Â 1 Â Â 0 01 Â Â 0 Â Â Â 8 Â S400 Â Â 0 Â Â 0W Â Â P Â Â C Â Â Â Â 0 Â Â 0 02 Â Â 1 Â Â Â 8 Â S400 Â Â 0 Â Â 0W Â Â P Â Â C Â Â Â Â 0 Â Â 0 03 Â Â 0 Â Â Â 8 Â S400 Â Â 0 Â Â 0W Â Â P Â Â - Â Â C Â 0 Â Â 0 04 Â Â 1 Â Â Â 8 Â S400 Â Â 1 Â -1W Â Â - Â Â C Â Â - Â 0 Â Â 0 Does this new info generate any new ideas about what the problem is, and how to get the VIA controller working? There are other cards that could go in that expansion slot. They are still putting VIA controllers on new mainboards.
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped