From bugmaster at FreeBSD.org Mon Aug 4 11:06:54 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 4 11:07:32 2008 Subject: Current problem reports assigned to freebsd-firewire@FreeBSD.org Message-ID: <200808041106.m74B6rpc082038@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/74238 firewire [firewire] fw_rcv: unknown response; firewire ad-hoc w 1 problem total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/113785 firewire [firewire] dropouts when playing DV on firewire 1 problem total. From freebsd at sopwith.solgatos.com Wed Aug 6 01:24:52 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Wed Aug 6 01:24:58 2008 Subject: This is where I'm going with fwcontrol Message-ID: <200808060123.BAA03303@sopwith.solgatos.com> > fwcontrol.c: In function 'main': > fwcontrol.c:726: warning: comparison is always false due to limited range of data type > > I changed priority_budget from int to long, is this the correct fix? I suspect that gcc will still complain on ILP32 machines. From freebsd at sopwith.solgatos.com Wed Aug 6 01:38:20 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Wed Aug 6 01:38:26 2008 Subject: This is where I'm going with fwcontrol In-Reply-To: Your message of "Tue, 01 Jul 2008 17:26:27 PDT." <486ACB33.50204@miralink.com> Message-ID: <200808060059.AAA24024@sopwith.solgatos.com> In message <486ACB33.50204@miralink.com>, Sean Bruno writes: > > Here is a current diff against RELENG_7 which seems to be the same as > > -CURRENT. fwcontrol.c: In function 'main': fwcontrol.c:726: warning: comparison is always false due to limited range of data type I changed priority_budget from int to long, is this the correct fix? BUG: + if (adjust_gap_count) + send_phy_config(fd, adjust_gap_count, -1); Since I need to set this to 0 (see PR 113785), the if() fails and doesn't execute the send_phy_config(). I fixed this by adding a seperate flag, need_to_send_adjust_gap_count. Please feel free to think up a better name for the flag. :-) NOTE: some of the other options have the same problem, if the argument can be 0. The patch below only fixes -f. I did add some error checking, mostly for malloc. With the patch below, -f, -r, -u, -S work for me. FreeBSD 7.0 on AMD64, with the NEC fw controller. I haven't tested -R yet, I suspect the VIA fw controller still doesn't work. =================================================================== RCS file: RCS/fwcontrol.c,v retrieving revision 1.3 diff -u -r1.3 fwcontrol.c --- fwcontrol.c 2008/08/05 23:16:45 1.3 +++ fwcontrol.c 2008/08/06 00:33:25 @@ -97,7 +97,7 @@ get_dev(int fd, struct fw_devlstreq *data) { if (data == NULL) - err(1, "malloc"); + err(1, "arg data is NULL"); /* probably due to failure of malloc in calling function */ if( ioctl(fd, FW_GDEVLST, data) < 0) { err(1, "ioctl"); } @@ -188,6 +188,8 @@ u_int32_t *qld, res; asyreq = (struct fw_asyreq *)malloc(sizeof(struct fw_asyreq_t) + 16); + if (asyreq == NULL) + err(1, "malloc"); asyreq->req.len = 16; #if 0 asyreq->req.type = FWASREQNODE; @@ -226,6 +228,8 @@ struct fw_asyreq *asyreq; asyreq = (struct fw_asyreq *)malloc(sizeof(struct fw_asyreq_t) + 12); + if (asyreq == NULL) + err(1, "malloc"); asyreq->req.len = 12; asyreq->req.type = FWASREQNODE; asyreq->pkt.mode.ld[0] = 0; @@ -251,6 +255,8 @@ struct fw_asyreq *asyreq; asyreq = (struct fw_asyreq *)malloc(sizeof(struct fw_asyreq_t) + 12); + if (asyreq == NULL) + err(1, "malloc"); asyreq->req.len = 12; asyreq->req.type = FWASREQNODE; asyreq->pkt.mode.common.tcode = FWTCODE_PHY; @@ -268,6 +274,8 @@ struct fw_asyreq *asyreq; asyreq = (struct fw_asyreq *)malloc(sizeof(struct fw_asyreq_t) + 16); + if (asyreq == NULL) + err(1, "malloc"); asyreq->req.len = 16; asyreq->req.type = FWASREQNODE; asyreq->pkt.mode.wreqq.dst = FWLOCALBUS | (node & 0x3f); @@ -643,7 +651,11 @@ err(1, "ioctl FW_SRSTREAM"); buf = (char *)malloc(1024*16); + if (buf == NULL) + err(1, "malloc"); len = read(fd, buf, 1024*16); + if (len == -1) + err(1, "read"); ptr = (u_int32_t *) buf; ciph = (struct ciphdr *)(ptr + 1); @@ -688,12 +700,13 @@ * to iterate through */ int display_board_only = 0; - int priority_budget = 0; + long priority_budget = 0; int display_crom = 0; char *crom_string = NULL; char *crom_string_hex = NULL; int display_crom_hex = 0; int adjust_gap_count = 0; + int need_to_send_adjust_gap_count = 0; int reset_gap_count = 0; int load_crom_from_file = 0; int set_fwmem_target = 0; @@ -731,6 +744,8 @@ break; case 'c': crom_string = malloc(strlen(optarg)+1); + if (crom_string == NULL) + err(1, "malloc"); strcpy(crom_string, optarg); display_crom = 1; open_needed = 1; @@ -739,6 +754,8 @@ break; case 'd': crom_string_hex = malloc(strlen(optarg)+1); + if (crom_string == NULL) + err(1, "malloc"); strcpy(crom_string_hex, optarg); display_crom_hex = 1; open_needed = 1; @@ -747,6 +764,7 @@ break; case 'f': adjust_gap_count = strtol(optarg, NULL, 0); + need_to_send_adjust_gap_count = 1; open_needed = 1; command_set = 1; display_board_only = 0; @@ -827,6 +845,8 @@ break; case 'R': recv_data = malloc(strlen(optarg)+1); + if (recv_data == NULL) + err(1, "malloc"); strcpy(recv_data, optarg); open_needed = 1; command_set = 1; @@ -834,6 +854,8 @@ break; case 'S': send_data = malloc(strlen(optarg)+1); + if (send_data == NULL) + err(1, "malloc"); strcpy(send_data, optarg); open_needed = 1; display_board_only = 0; @@ -904,8 +926,10 @@ /* * Adjust the gap count for this card/bus to value "-f" */ - if (adjust_gap_count) + if (need_to_send_adjust_gap_count) + { send_phy_config(fd, adjust_gap_count, -1); + } /* * Reset the gap count for this card/bus "-g" From sbruno at miralink.com Sat Aug 9 20:12:30 2008 From: sbruno at miralink.com (Sean Bruno) Date: Sat Aug 9 20:12:37 2008 Subject: This is where I'm going with fwcontrol In-Reply-To: <200808060123.BAA03303@sopwith.solgatos.com> References: <200808060123.BAA03303@sopwith.solgatos.com> Message-ID: <489DFA2C.4080407@miralink.com> Dieter wrote: >> fwcontrol.c: In function 'main': >> fwcontrol.c:726: warning: comparison is always false due to limited range of data type >> >> I changed priority_budget from int to long, is this the correct fix? >> > > I suspect that gcc will still complain on ILP32 machines. > Sorry for the delay...See the attached patch and test it on unpatched 6/7/8 as fwcontrol is the same on all platforms. I implemented your fix for priority_budget, i.e. I should have been paying attention to the conditional test and the assignment from strtol()! Also, I changed some of the variable to check for >= 0 and set their default values to -1. This should have the same effect as adding a new variable as you did in your fix. Let me know what you think! -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Cell 503-358-6832 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com From sbruno at miralink.com Sat Aug 9 20:14:00 2008 From: sbruno at miralink.com (Sean Bruno) Date: Sat Aug 9 20:14:06 2008 Subject: This is where I'm going with fwcontrol(now with actual patch) In-Reply-To: <200808060123.BAA03303@sopwith.solgatos.com> References: <200808060123.BAA03303@sopwith.solgatos.com> Message-ID: <489DFA86.4010507@miralink.com> Dieter wrote: >> fwcontrol.c: In function 'main': >> fwcontrol.c:726: warning: comparison is always false due to limited range of data type >> >> I changed priority_budget from int to long, is this the correct fix? >> > > I suspect that gcc will still complain on ILP32 machines. > Sorry for the delay...See the attached patch and test it on unpatched 6/7/8 as fwcontrol is the same on all platforms. I implemented your fix for priority_budget, i.e. I should have been paying attention to the conditional test and the assignment from strtol()! Also, I changed some of the variable to check for >= 0 and set their default values to -1. This should have the same effect as adding a new variable as you did in your fix. Let me know what you think! -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Cell 503-358-6832 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fwcontrol.diff Type: text/x-patch Size: 12252 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-firewire/attachments/20080809/776b7ce5/fwcontrol.bin From bugmaster at FreeBSD.org Mon Aug 11 11:06:56 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 11 11:07:30 2008 Subject: Current problem reports assigned to freebsd-firewire@FreeBSD.org Message-ID: <200808111106.m7BB6tEq047165@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/74238 firewire [firewire] fw_rcv: unknown response; firewire ad-hoc w 1 problem total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/113785 firewire [firewire] dropouts when playing DV on firewire 1 problem total. From freebsd at sopwith.solgatos.com Mon Aug 11 23:52:08 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Mon Aug 11 23:52:14 2008 Subject: This is where I'm going with fwcontrol In-Reply-To: Your message of "Sat, 09 Aug 2008 13:12:28 PDT." <489DFA2C.4080407@miralink.com> Message-ID: <200808112347.XAA02248@sopwith.solgatos.com> [ I suggested changing priority_budget from int to long, but then realized that this only fixes it on LP64, not on ILP32. ] >> I suspect that gcc will still complain on ILP32 machines. > I implemented your fix for priority_budget, i.e. I should have been > paying attention to the conditional test and the assignment from strtol()! What arch are you compiling this on? Does gcc not complain on a ILP32 machine? If the intended legal range is 0-4294967295, a 32 bit signed integer isn't going to work. On ILP32, (long)0xffffffff has a value of -1, assuming 2's complement. Actually, strtol returns long, so the largest positive number it can return is 0x7fffffff = 2147483647. If we need 0-4294967295 perhaps use strtoll() which returns long long. ------------- On the fwcontrol man page, should -i pri_req Set the PRIORITY_BUDGET register on all supported nodes. be -b pri_req Set the PRIORITY_BUDGET register on all supported nodes. ? For the benefit of end users who are not firewire wizards, it would be nice for the man page to include the range of legal values and what they mean. From freebsd at sopwith.solgatos.com Tue Aug 12 00:07:35 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Tue Aug 12 00:07:42 2008 Subject: This is where I'm going with fwcontrol In-Reply-To: Your message of "Sat, 09 Aug 2008 13:12:28 PDT." <489DFA2C.4080407@miralink.com> Message-ID: <200808120006.AAA04467@sopwith.solgatos.com> A patch that adds error checking to malloc() and read(): =================================================================== RCS file: RCS/fwcontrol.c,v retrieving revision 1.2.1.1 diff -u -r1.2.1.1 fwcontrol.c --- fwcontrol.c 2008/08/11 20:47:34 1.2.1.1 +++ fwcontrol.c 2008/08/12 00:02:37 @@ -188,6 +188,8 @@ u_int32_t *qld, res; asyreq = (struct fw_asyreq *)malloc(sizeof(struct fw_asyreq_t) + 16); + if (asyreq == NULL) + err(1, "malloc"); asyreq->req.len = 16; #if 0 asyreq->req.type = FWASREQNODE; @@ -226,6 +228,8 @@ struct fw_asyreq *asyreq; asyreq = (struct fw_asyreq *)malloc(sizeof(struct fw_asyreq_t) + 12); + if (asyreq == NULL) + err(1, "malloc"); asyreq->req.len = 12; asyreq->req.type = FWASREQNODE; asyreq->pkt.mode.ld[0] = 0; @@ -251,6 +255,8 @@ struct fw_asyreq *asyreq; asyreq = (struct fw_asyreq *)malloc(sizeof(struct fw_asyreq_t) + 12); + if (asyreq == NULL) + err(1, "malloc"); asyreq->req.len = 12; asyreq->req.type = FWASREQNODE; asyreq->pkt.mode.common.tcode = FWTCODE_PHY; @@ -268,6 +274,8 @@ struct fw_asyreq *asyreq; asyreq = (struct fw_asyreq *)malloc(sizeof(struct fw_asyreq_t) + 16); + if (asyreq == NULL) + err(1, "malloc"); asyreq->req.len = 16; asyreq->req.type = FWASREQNODE; asyreq->pkt.mode.wreqq.dst = FWLOCALBUS | (node & 0x3f); @@ -643,7 +651,11 @@ err(1, "ioctl FW_SRSTREAM"); buf = (char *)malloc(1024*16); + if (buf == NULL) + err(1, "malloc"); len = read(fd, buf, 1024*16); + if (len < 0) + err(1, "read"); ptr = (u_int32_t *) buf; ciph = (struct ciphdr *)(ptr + 1); @@ -731,6 +743,8 @@ break; case 'c': crom_string = malloc(strlen(optarg)+1); + if (crom_string == NULL) + err(1, "malloc"); strcpy(crom_string, optarg); display_crom = 1; open_needed = 1; @@ -739,6 +753,8 @@ break; case 'd': crom_string_hex = malloc(strlen(optarg)+1); + if (crom_string_hex == NULL) + err(1, "malloc"); strcpy(crom_string_hex, optarg); display_crom_hex = 1; open_needed = 1; @@ -827,6 +843,8 @@ break; case 'R': recv_data = malloc(strlen(optarg)+1); + if (recv_data == NULL) + err(1, "malloc"); strcpy(recv_data, optarg); open_needed = 1; command_set = 1; @@ -834,6 +852,8 @@ break; case 'S': send_data = malloc(strlen(optarg)+1); + if (send_data == NULL) + err(1, "malloc"); strcpy(send_data, optarg); open_needed = 1; display_board_only = 0; From freebsd at sopwith.solgatos.com Tue Aug 12 00:24:25 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Tue Aug 12 00:24:31 2008 Subject: This is where I'm going with fwcontrol In-Reply-To: Your message of "Sat, 09 Aug 2008 13:12:28 PDT." <489DFA2C.4080407@miralink.com> Message-ID: <200808120023.AAA02381@sopwith.solgatos.com> The man page doesn't document the -f option. The usage message doesn't list -M. From freebsd at sopwith.solgatos.com Tue Aug 12 00:34:37 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Tue Aug 12 00:34:42 2008 Subject: This is where I'm going with fwcontrol In-Reply-To: Your message of "Sat, 09 Aug 2008 13:12:28 PDT." <489DFA2C.4080407@miralink.com> Message-ID: <200808120033.AAA07139@sopwith.solgatos.com> > Also, I changed some of the variable to check for >= 0 and set their > default values to -1. This should have the same effect as adding a new > variable as you did in your fix. If you're going to do it that way, the code should check that the argument is in range, and print a complaint if out of range. Otherwise the user could say "fwcontrol -f -1" and nothing would happen. And the man page should list the legal range. Hmmm, actually these should be done even with the add-a-new-variable method. From sbruno at miralink.com Tue Aug 12 01:07:30 2008 From: sbruno at miralink.com (Sean Bruno) Date: Tue Aug 12 01:07:37 2008 Subject: This is where I'm going with fwcontrol In-Reply-To: <200808120033.AAA07139@sopwith.solgatos.com> References: <200808120033.AAA07139@sopwith.solgatos.com> Message-ID: <48A0E237.5020702@miralink.com> Dieter wrote: >> Also, I changed some of the variable to check for >= 0 and set their >> default values to -1. This should have the same effect as adding a new >> variable as you did in your fix. >> > > If you're going to do it that way, the code should check that the argument > is in range, and print a complaint if out of range. Otherwise the user could > say "fwcontrol -f -1" and nothing would happen. And the man page should list > the legal range. Hmmm, actually these should be done even with the > add-a-new-variable method. > Excellent feedback, let me work on something tonight and reissue the patch. -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Cell 503-358-6832 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com From sbruno at miralink.com Sun Aug 17 03:46:00 2008 From: sbruno at miralink.com (Sean Bruno) Date: Sun Aug 17 03:46:07 2008 Subject: fwcontrol update Message-ID: <48A79EF5.5010805@miralink.com> I think that this is much closer to the finished product now. I've incorporated a lot of error checking and error reporting in this version(thanks Dieter!). I cleaned up the usage() summary along with the man page just a bit at Dieter's suggestion as well. The main changes are around the use of booleans for many of the new variables instead of integers. Also, I believe declaring the majority of the new integers as "int32_t" instead of "int" will ensure that the x86_64 compile doesn't spew any warnings, but I'd like a quick review please. Finally, this patch should work across 6/7/HEAD AFAIK. I've tested 6 and 7 under i368/i686 architectures. -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Cell 503-358-6832 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fwcontrol.diff Type: text/x-patch Size: 19187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-firewire/attachments/20080817/4dbdbd9c/fwcontrol.bin From freebsd at sopwith.solgatos.com Sun Aug 17 17:06:27 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Sun Aug 17 17:06:33 2008 Subject: fwcontrol update In-Reply-To: Your message of "Sat, 16 Aug 2008 20:45:57 PDT." <48A79EF5.5010805@miralink.com> Message-ID: <200808171705.RAA12502@sopwith.solgatos.com> > len = read(fd, buf, 1024*16); It would be good practice to check for read failing. From sbruno at miralink.com Sun Aug 17 17:34:53 2008 From: sbruno at miralink.com (Sean Bruno) Date: Sun Aug 17 17:35:01 2008 Subject: fwcontrol update In-Reply-To: <200808171705.RAA12502@sopwith.solgatos.com> References: <200808171705.RAA12502@sopwith.solgatos.com> Message-ID: <48A8613A.4000506@miralink.com> Dieter wrote: >> len = read(fd, buf, 1024*16); >> > > It would be good practice to check for read failing. > Indeed it would. I looked into fwdev.c::fw_read() a little bit and documented what I think it's doing as well. -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Cell 503-358-6832 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fwcontrol.diff Type: text/x-patch Size: 20014 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-firewire/attachments/20080817/03ddbeaf/fwcontrol.bin From sbruno at miralink.com Sun Aug 17 17:43:19 2008 From: sbruno at miralink.com (Sean Bruno) Date: Sun Aug 17 17:43:25 2008 Subject: fwcontrol update In-Reply-To: <200808171705.RAA12502@sopwith.solgatos.com> References: <200808171705.RAA12502@sopwith.solgatos.com> Message-ID: <48A86335.8060508@miralink.com> Dieter wrote: >> len = read(fd, buf, 1024*16); >> > > It would be good practice to check for read failing. > BTW, did the compile warnings on AMD64 go away? -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Cell 503-358-6832 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com From freebsd at sopwith.solgatos.com Sun Aug 17 23:10:22 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Sun Aug 17 23:10:28 2008 Subject: fwcontrol update In-Reply-To: Your message of "Sun, 17 Aug 2008 10:34:50 PDT." <48A8613A.4000506@miralink.com> Message-ID: <200808172309.XAA21188@sopwith.solgatos.com> > >> len = read(fd, buf, 1024*16); > > > > It would be good practice to check for read failing. > > Indeed it would. I looked into fwdev.c::fw_read() a little bit and > documented what I think it's doing as well. > BTW, did the compile warnings on AMD64 go away? I still need to give it a closer inspection, and run some tests, but it looks good so far. And gcc isn't complaining (7.0 on AMD64). From bugmaster at FreeBSD.org Mon Aug 18 11:06:49 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 18 11:07:30 2008 Subject: Current problem reports assigned to freebsd-firewire@FreeBSD.org Message-ID: <200808181106.m7IB6msh079779@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/74238 firewire [firewire] fw_rcv: unknown response; firewire ad-hoc w 1 problem total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/113785 firewire [firewire] dropouts when playing DV on firewire 1 problem total. From freebsd at sopwith.solgatos.com Mon Aug 18 19:14:34 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Mon Aug 18 19:14:43 2008 Subject: fwcontrol update In-Reply-To: Your message of "Sun, 17 Aug 2008 10:43:17 PDT." <48A86335.8060508@miralink.com> Message-ID: <200808181913.TAA21449@sopwith.solgatos.com> case 'b': if (priority_budget < 0 || priority_budget > INT32_MAX) errx(EX_USAGE, "%s: invalid number: %s", __func__, optarg); case 'f': if ( (adjust_gap_count < 0) || (adjust_gap_count > INT32_MAX) ) err(EX_USAGE, "%s:adjust_gap_count out of range", __func__); I think "out of range" is better than "invalid number". -5 is a valid number. Just a minor nit, feel free to ignore this one. :-) ================================================================================ > case 'c': > crom_string = malloc(strlen(optarg)+1); > if (crom_string == NULL) > err(EX_SOFTWARE, "%s:crom_string malloc", __func__); > if ( (strtol(crom_string, NULL, 0) < 0) || strtol(crom_string, NULL, 0) > MAX_BOARDS) > err(EX_USAGE, "%s:Invalid value for node", __func__); > strcpy(crom_string, optarg); Strtol() reads freshly malloc-ed memory before anything has been put there. Perhaps: case 'c': { long node_num; node_num = strtol(optarg, NULL, 0); if ( (node_num < 0) || (node_num > MAX_BOARDS) ) err(EX_USAGE, "%s:node out of range", __func__); crom_string = malloc(strlen(optarg)+1); if (crom_string == NULL) err(EX_SOFTWARE, "%s:crom_string malloc", __func__); strcpy(crom_string, optarg); ... } case 'd': ================================================================================ case 'u': current_board = strtol(optarg, NULL, 0); Does this need a range check? ================================================================================ From sbruno at miralink.com Mon Aug 18 19:21:28 2008 From: sbruno at miralink.com (Sean Bruno) Date: Mon Aug 18 19:21:34 2008 Subject: fwcontrol update In-Reply-To: <200808181913.TAA21449@sopwith.solgatos.com> References: <200808181913.TAA21449@sopwith.solgatos.com> Message-ID: <48A9CBB5.6030402@miralink.com> Dieter wrote: > case 'b': > > if (priority_budget < 0 || priority_budget > INT32_MAX) > errx(EX_USAGE, "%s: invalid number: %s", __func__, optarg); > > case 'f': > > if ( (adjust_gap_count < 0) || (adjust_gap_count > INT32_MAX) ) > err(EX_USAGE, "%s:adjust_gap_count out of range", __func__); > > > I think "out of range" is better than "invalid number". > -5 is a valid number. > current_board = strtol(optarg, NULL, 0); > Just a minor nit, feel free to ignore this one. :-) > > ================================================================================ > > Agreed. It's a nit, but I'll change it. >> case 'c': >> crom_string = malloc(strlen(optarg)+1); >> if (crom_string == NULL) >> err(EX_SOFTWARE, "%s:crom_string malloc", __func__); >> if ( (strtol(crom_string, NULL, 0) < 0) || strtol(crom_string, NULL, 0) > MAX_BOARDS) >> err(EX_USAGE, "%s:Invalid value for node", __func__); >> strcpy(crom_string, optarg); >> > > Strtol() reads freshly malloc-ed memory before anything has been put there. > > Perhaps: > > case 'c': > { > long node_num; > node_num = strtol(optarg, NULL, 0); > if ( (node_num < 0) || (node_num > MAX_BOARDS) ) > err(EX_USAGE, "%s:node out of range", __func__); > crom_string = malloc(strlen(optarg)+1); > if (crom_string == NULL) > err(EX_SOFTWARE, "%s:crom_string malloc", __func__); > strcpy(crom_string, optarg); > > ... > > } > case 'd': > > > ================================================================================ > > This is a big ol' whoops on my part. The whole "malloc" and copy thing just seems pointless and needs to be consolidated into just a "strtol()" instead. > case 'u': > > current_board = strtol(optarg, NULL, 0); > > Does this need a range check? > > ================================================================================ > Probably should be a range check( current_board < 0 and current_board > MAX_BOARDS). -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com From freebsd at sopwith.solgatos.com Mon Aug 18 21:50:38 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Mon Aug 18 21:50:45 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: Your message of "Mon, 18 Aug 2008 12:21:25 PDT." <48A9CBB5.6030402@miralink.com> Message-ID: <200808182148.VAA27124@sopwith.solgatos.com> Am I correct in assuming that none of this stuff that fwcontrol sets should carry across a reboot? And that the firewire controller should get completely reset by a reboot? I'm getting some bad results. Attempt to recover: Changed symlink from current fwcontrol to known working fwcontrol_prev. Powered off camcorder. Rebooted FreeBSD. Powered on camcorder. Ran fix_dv script to get FreeBSD into "non CYCLEMASTER mode". fwcontrol -u 1 -f 0 fwcontrol -u 1 -r Start playing a tape (so I can run fwcontrol -R) FreeBSD console starts spewing: fwohci1: Initiate bus reset fwohci1: BUS reset fwohci1: node_id=0x8000ffc0, gen=4, non CYCLEMASTER mode <-- from fix_dv script firewire1: 2 nodes, maxhop <= 1, cable IRM = 1 fwohci1: BUS reset fwohci1: node_id=0xc000ffc1, gen=7, CYCLEMASTER mode firewire1: 2 nodes, maxhop <= 1, cable IRM = 1 (me) firewire1: bus manager 1 (me) got BUSRST packet!? fwohci1: BUS reset fwohci1: node_id=0xc000ffc1, gen=8, CYCLEMASTER mode firewire1: 2 nodes, maxhop <= 1, cable IRM = 1 (me) firewire1: bus manager 1 (me) fwohci1: BUS reset fwohci1: node_id=0xc000ffc0, gen=12, CYCLEMASTER mode firewire1: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire1: bus manager 0 (me) got BUSRST packet!? got BUSRST packet!? got BUSRST packet!? fwohci1: BUS reset fwohci1: node_id=0xc000ffc1, gen=33, CYCLEMASTER mode firewire1: 2 nodes, maxhop <= 1, cable IRM = 1 (me) firewire1: bus manager 0 fwohci1: BUS reset fwohci1: node_id=0xc000ffc0, gen=38, CYCLEMASTER mode firewire1: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire1: bus manager 0 (me) got BUSRST packet!? got BUSRST packet!? fwohci1: BUS reset fwohci1: node_id=0xc000ffc1, gen=57, CYCLEMASTER mode firewire1: 2 nodes, maxhop <= 1, cable IRM = 1 (me) firewire1: bus manager 0 fwohci1: BUS reset fwohci1: node_id=0xc000ffc0, gen=62, CYCLEMASTER mode firewire1: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire1: bus manager 0 (me) got BUSRST packet!? got BUSRST packet!? got BUSRST packet!? fwohci1: BUS reset ... fwohci1: node_id=0xc000ffc0, gen=122, CYCLEMASTER mode firewire1: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire1: bus manager 0 (me) got BUSRST packet!? got BUSRST packet!? fwohci1: BUS reset fwohci1: node_id=0xc000ffc1, gen=144, CYCLEMASTER mode firewire1: 2 nodes, maxhop <= 1, cable IRM = 1 (me) firewire1: bus manager 0 Stopping the camcorder stops the spewing. Needless to say, fwcontrol -R no longer works. I ran the fixit script again, and fwcontrol -S does work. I notice that it doesn't print every generation. I notice that the node_id changes. FreeBSD 7.0 AMD64 fw controller: NEC uPD72871/2 Ideas? From sbruno at miralink.com Mon Aug 18 22:27:02 2008 From: sbruno at miralink.com (Sean Bruno) Date: Mon Aug 18 22:27:08 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: <200808182148.VAA27124@sopwith.solgatos.com> References: <200808182148.VAA27124@sopwith.solgatos.com> Message-ID: <48A9F735.5090507@miralink.com> Dieter wrote: > Am I correct in assuming that none of this stuff that > fwcontrol sets should carry across a reboot? And that > the firewire controller should get completely reset > by a reboot? > > My assumption is that no settings should survive a reboot. > I'm getting some bad results. Attempt to recover: > > Changed symlink from current fwcontrol to known working fwcontrol_prev. > Powered off camcorder. > Rebooted FreeBSD. > Powered on camcorder. > Ran fix_dv script to get FreeBSD into "non CYCLEMASTER mode". > fwcontrol -u 1 -f 0 > fwcontrol -u 1 -r > Start playing a tape (so I can run fwcontrol -R) > > Hrm ... the old code closed "fd" and then re-opened it. I have duplicated that behavior in the attached patch. > Needless to say, fwcontrol -R no longer works. > > I ran the fixit script again, and fwcontrol -S does work. > > I notice that it doesn't print every generation. > I notice that the node_id changes. > > This alarms me quite a bit. I didn't think there was anyway for the generation to change without the log message being spit out. Interesting. I have been suspicious of a race condition for some time in the firewire stack, I see it across multiple devices(sbp, sbp_targ) and now fwcontrol is acting weird. Very interesting. > FreeBSD 7.0 > AMD64 > fw controller: NEC uPD72871/2 > > Ideas? > Yes. Try the attached patch. Let me know. -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com From freebsd at sopwith.solgatos.com Mon Aug 18 23:11:03 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Mon Aug 18 23:11:08 2008 Subject: fwcontrol update In-Reply-To: Your message of "Mon, 18 Aug 2008 12:21:25 PDT." <48A9CBB5.6030402@miralink.com> Message-ID: <200808182301.XAA20058@sopwith.solgatos.com> Here are some testing results from before I noticed the console spew problem: # fwcontrol -f -6 fwcontrol: main:adjust_gap_count out of range: No such file or directory The "out of range" is expected. The "No such file or directory" part seems wrong. ====================================================== # fwcontrol -c -7 fwcontrol: no such node -1. Interesting that -7 becomes -1. -d does the same thing. BTW, running fwcontrol with no arguments does print out a line with node -1. Whatever that means. ====================================================== Now test things that should work: fwcontrol -u 1 -f 0 works fwcontrol -u 1 -r works fwcontrol -u 1 -S /dev/stdin works fwcontrol -u 1 -R camera.dv fwcontrol: detect_recv_fn: error reading from device : Resource temporarily unavailable fwcontrol_prev -u 1 -R camera.dv Detected DV format on input. (EAGAIN) (EAGAIN) (EAGAIN) And then I noticed the console spewing away as reported in my previous message, and tried rebooting... From freebsd at sopwith.solgatos.com Mon Aug 18 23:59:17 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Mon Aug 18 23:59:23 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: Your message of "Mon, 18 Aug 2008 15:27:01 PDT." <48A9F735.5090507@miralink.com> Message-ID: <200808182355.XAA09163@sopwith.solgatos.com> > > I notice that it doesn't print every generation. > > I notice that the node_id changes. > > > This alarms me quite a bit. I didn't think there was anyway for the > generation to change > without the log message being spit out. Interesting. It also skips on dmesg, so it isn't a console problem: fwohci1: node_id=0xc000ffc0, gen=86, CYCLEMASTER mode firewire1: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire1: bus manager 0 (me) got BUSRST packet!? got BUSRST packet!? got BUSRST packet!? fwohci1: BUS reset fwohci1: node_id=0xc000ffc1, gen=108, CYCLEMASTER mode firewire1: 2 nodes, maxhop <= 1, cable IRM = 1 (me) firewire1: bus manager 0 fwohci1: BUS reset fwohci1: node_id=0xc000ffc0, gen=112, CYCLEMASTER mode fwohci1: invalid SID len = 0 <-----------------------<<< didn't notice this line before fwohci1: BUS reset only occurs twice in dmesg fwohci1: node_id=0xc000ffc1, gen=130, CYCLEMASTER mode firewire1: 2 nodes, maxhop <= 1, cable IRM = 1 (me) firewire1: bus manager 1 (me) fwohci1: BUS reset fwohci1: node_id=0xc000ffc0, gen=135, CYCLEMASTER mode firewire1: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire1: bus manager 0 (me) got BUSRST packet!? got BUSRST packet!? fwohci1: BUS reset fwohci1: node_id=0xc000ffc1, gen=154, CYCLEMASTER mode Does "got BUSRST packet!?" mean that the camera is sending out bus reset commands? That doesn't seem right. BTW, shouldn't that line have a prefix telling where it comes from (e.g. fwohci1: or firewire1:) ? BTW there is just the FreeBSD box and the camera, no other nodes on the firewire bus. > I have been suspicious of a race condition for some time in the firewire > stack, I see it across multiple > devices(sbp, sbp_targ) and now fwcontrol is acting weird. Very interesting. > Yes. Try the attached patch. Let me know. I don't see a patch. Note that fwcontrol is not running when the spew happens. I press play on the camcorder, and the spewing starts. I press stop and the spewing stops. My only theories are that fwcontrol set something that survives a reboot, or that the fw controller chip isn't getting completely reset and properly initialized. I'm leaning towards the chip being the more likely explaination. From sbruno at miralink.com Tue Aug 19 00:03:04 2008 From: sbruno at miralink.com (Sean Bruno) Date: Tue Aug 19 00:03:12 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: <200808182355.XAA09163@sopwith.solgatos.com> References: <200808182355.XAA09163@sopwith.solgatos.com> Message-ID: <48AA0DB0.2020306@miralink.com> Dieter wrote: >>> I notice that it doesn't print every generation. >>> I notice that the node_id changes. >>> >> This alarms me quite a bit. I didn't think there was anyway for the >> generation to change >> without the log message being spit out. Interesting. >> > > It also skips on dmesg, so it isn't a console problem: > > fwohci1: node_id=0xc000ffc0, gen=86, CYCLEMASTER mode > firewire1: 1 nodes, maxhop <= 0, cable IRM = 0 (me) > firewire1: bus manager 0 (me) > got BUSRST packet!? > got BUSRST packet!? > got BUSRST packet!? > fwohci1: BUS reset > fwohci1: node_id=0xc000ffc1, gen=108, CYCLEMASTER mode > firewire1: 2 nodes, maxhop <= 1, cable IRM = 1 (me) > firewire1: bus manager 0 > fwohci1: BUS reset > fwohci1: node_id=0xc000ffc0, gen=112, CYCLEMASTER mode > fwohci1: invalid SID len = 0 <-----------------------<<< didn't notice this line before > fwohci1: BUS reset only occurs twice in dmesg > fwohci1: node_id=0xc000ffc1, gen=130, CYCLEMASTER mode > firewire1: 2 nodes, maxhop <= 1, cable IRM = 1 (me) > firewire1: bus manager 1 (me) > fwohci1: BUS reset > fwohci1: node_id=0xc000ffc0, gen=135, CYCLEMASTER mode > firewire1: 1 nodes, maxhop <= 0, cable IRM = 0 (me) > firewire1: bus manager 0 (me) > got BUSRST packet!? > got BUSRST packet!? > fwohci1: BUS reset > fwohci1: node_id=0xc000ffc1, gen=154, CYCLEMASTER mode > > Does "got BUSRST packet!?" mean that the camera is sending out > bus reset commands? That doesn't seem right. BTW, shouldn't that > line have a prefix telling where it comes from (e.g. fwohci1: > or firewire1:) ? > > BTW there is just the FreeBSD box and the camera, no other nodes > on the firewire bus. > > thanks, that's good to know. >> I have been suspicious of a race condition for some time in the firewire >> stack, I see it across multiple >> devices(sbp, sbp_targ) and now fwcontrol is acting weird. Very interesting. >> > > >> Yes. Try the attached patch. Let me know. >> > > I don't see a patch. > > Doh! Let me attach it this time! :) > Note that fwcontrol is not running when the spew happens. > I press play on the camcorder, and the spewing starts. > I press stop and the spewing stops. > > My only theories are that fwcontrol set something that > survives a reboot, or that the fw controller chip isn't > getting completely reset and properly initialized. I'm > leaning towards the chip being the more likely explaination. > fwcontrol is ridiculously dangerous IMO. It is a userland app that does raw direct access to registers on firewire devices. I would think that some kind of safety wrapper/API is in order here. -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com -------------- next part -------------- Index: fwcontrol.8 =================================================================== --- fwcontrol.8 (revision 5721) +++ fwcontrol.8 (working copy) @@ -59,7 +59,7 @@ The following options are available: .Bl -tag -width indent .It Fl u Ar bus_num -Specify the FireWire bus number to be operated on. +Specify the FireWire bus number to be operated on. Default is bus 0. .It Fl r Initiate bus reset. .It Fl t Index: fwcontrol.c =================================================================== --- fwcontrol.c (revision 5721) +++ fwcontrol.c (working copy) @@ -56,6 +56,8 @@ #include #include #include +#include +#include #include "fwmethods.h" static void sysctl_set_int(const char *, int); @@ -64,21 +66,22 @@ usage(void) { fprintf(stderr, - "fwcontrol [-u bus_num] [-rt] [-f node] [-g gap_count] " - "[-o node] " - "[-b pri_req] [-c node] [-d node] [-l file] " - "[-R file] [-S file] [-m target]\n" + "fwcontrol [-u bus_num] [-prt] [-c node] [-d node] [-o node] [-s node]\n" + "\t [-l file] [-g gap_count] [-f force_root ] [-b pri_req]\n" + "\t [-M mode] [-R filename] [-S filename] [-m EUI64 | hostname]\n" "\t-u: specify bus number\n" - "\t-f: broadcast force_root by phy_config packet\n" - "\t-g: broadcast gap_count by phy_config packet\n" - "\t-o: send link-on packet to the node\n" - "\t-s: write RESET_START register on the node\n" - "\t-b: set PRIORITY_BUDGET register on all supported nodes\n" - "\t-c: read configuration ROM\n" + "\t-p: Display current PHY register settings\n" "\t-r: bus reset\n" "\t-t: read topology map\n" + "\t-c: read configuration ROM\n" "\t-d: hex dump of configuration ROM\n" + "\t-o: send link-on packet to the node\n" + "\t-s: write RESET_START register on the node\n" "\t-l: load and parse hex dump file of configuration ROM\n" + "\t-g: broadcast gap_count by phy_config packet\n" + "\t-f: broadcast force_root by phy_config packet\n" + "\t-b: set PRIORITY_BUDGET register on all supported nodes\n" + "\t-M: specify dv or mpeg\n" "\t-R: Receive DV or MPEG TS stream\n" "\t-S: Send DV stream\n" "\t-m: set fwmem target\n"); @@ -92,18 +95,14 @@ *(u_int32_t*)&(eui->octet[4]) = htonl(fweui->lo); } -static struct fw_devlstreq * -get_dev(int fd) +static void +get_dev(int fd, struct fw_devlstreq *data) { - struct fw_devlstreq *data; - - data = (struct fw_devlstreq *)malloc(sizeof(struct fw_devlstreq)); if (data == NULL) - err(1, "malloc"); + err(EX_SOFTWARE, "%s: data malloc", __func__); if( ioctl(fd, FW_GDEVLST, data) < 0) { - err(1, "ioctl"); + err(EX_IOERR, "%s: ioctl", __func__); } - return data; } static int @@ -130,17 +129,25 @@ if (eui64_hostton(nodestr, &eui) != 0 && eui64_aton(nodestr, &eui) != 0) return (-1); - data = get_dev(fd); + data = (struct fw_devlstreq *)malloc(sizeof(struct fw_devlstreq)); + if (data == NULL) + err(EX_SOFTWARE, "%s: data malloc", __func__); + get_dev(fd,data); for (i = 0; i < data->info_len; i++) { fweui2eui64(&data->dev[i].eui, &tmpeui); if (memcmp(&eui, &tmpeui, sizeof(struct eui64)) == 0) { node = data->dev[i].dst; + if (data != NULL) + free(data); goto gotnode; } } - if (i >= data->info_len) + if (i >= data->info_len) { + if (data != NULL) + free(data); return (-1); + } gotnode: if (node < 0 || node > 63) @@ -158,7 +165,10 @@ char addr[EUI64_SIZ], hostname[40]; int i; - data = get_dev(fd); + data = (struct fw_devlstreq *)malloc(sizeof(struct fw_devlstreq)); + if (data == NULL) + err(EX_SOFTWARE, "%s:data malloc", __func__); + get_dev(fd, data); printf("%d devices (info_len=%d)\n", data->n, data->info_len); printf("node EUI64 status hostname\n"); for (i = 0; i < data->info_len; i++) { @@ -184,6 +194,8 @@ u_int32_t *qld, res; asyreq = (struct fw_asyreq *)malloc(sizeof(struct fw_asyreq_t) + 16); + if (asyreq == NULL) + err(EX_SOFTWARE, "%s:asyreq malloc", __func__); asyreq->req.len = 16; #if 0 asyreq->req.type = FWASREQNODE; @@ -206,7 +218,7 @@ asyreq->pkt.mode.wreqq.data = htonl(data); if (ioctl(fd, FW_ASYREQ, asyreq) < 0) { - err(1, "ioctl"); + err(EX_IOERR, "%s: ioctl", __func__); } res = qld[3]; free(asyreq); @@ -222,6 +234,8 @@ struct fw_asyreq *asyreq; asyreq = (struct fw_asyreq *)malloc(sizeof(struct fw_asyreq_t) + 12); + if (asyreq == NULL) + err(EX_SOFTWARE, "%s:asyreq malloc", __func__); asyreq->req.len = 12; asyreq->req.type = FWASREQNODE; asyreq->pkt.mode.ld[0] = 0; @@ -237,16 +251,18 @@ root_node, gap_count); if (ioctl(fd, FW_ASYREQ, asyreq) < 0) - err(1, "ioctl"); + err(EX_IOERR, "%s: ioctl", __func__); free(asyreq); } static void -send_link_on(int fd, int node) +link_on(int fd, int node) { struct fw_asyreq *asyreq; asyreq = (struct fw_asyreq *)malloc(sizeof(struct fw_asyreq_t) + 12); + if (asyreq == NULL) + err(EX_SOFTWARE, "%s:asyreq malloc", __func__); asyreq->req.len = 12; asyreq->req.type = FWASREQNODE; asyreq->pkt.mode.common.tcode = FWTCODE_PHY; @@ -254,7 +270,7 @@ asyreq->pkt.mode.ld[2] = ~asyreq->pkt.mode.ld[1]; if (ioctl(fd, FW_ASYREQ, asyreq) < 0) - err(1, "ioctl"); + err(EX_IOERR, "%s: ioctl", __func__); free(asyreq); } @@ -264,6 +280,8 @@ struct fw_asyreq *asyreq; asyreq = (struct fw_asyreq *)malloc(sizeof(struct fw_asyreq_t) + 16); + if (asyreq == NULL) + err(EX_SOFTWARE, "%s:asyreq malloc", __func__); asyreq->req.len = 16; asyreq->req.type = FWASREQNODE; asyreq->pkt.mode.wreqq.dst = FWLOCALBUS | (node & 0x3f); @@ -276,7 +294,7 @@ asyreq->pkt.mode.wreqq.data = htonl(0x1); if (ioctl(fd, FW_ASYREQ, asyreq) < 0) - err(1, "ioctl"); + err(EX_IOERR, "%s: ioctl", __func__); free(asyreq); } @@ -290,7 +308,10 @@ u_int32_t max, reg, old; int i; - data = get_dev(fd); + data = (struct fw_devlstreq *)malloc(sizeof(struct fw_devlstreq)); + if (data == NULL) + err(EX_SOFTWARE, "%s:data malloc", __func__); + get_dev(fd, data); #define BUGET_REG 0xf0000218 for (i = 0; i < data->info_len; i++) { devinfo = &data->dev[i]; @@ -344,7 +365,10 @@ int i, error; struct fw_devlstreq *data; - data = get_dev(fd); + data = (struct fw_devlstreq *)malloc(sizeof(struct fw_devlstreq)); + if (data == NULL) + err(EX_SOFTWARE, "%s:data malloc", __func__); + get_dev(fd, data); for (i = 0; i < data->info_len; i++) { if (data->dev[i].dst == node && data->dev[i].eui.lo != 0) @@ -360,7 +384,7 @@ buf.ptr = crom_buf; bzero(crom_buf, len); if ((error = ioctl(fd, FW_GCROM, &buf)) < 0) { - err(1, "ioctl"); + err(EX_IOERR, "%s: ioctl", __func__); } return error; @@ -469,9 +493,9 @@ static const char *speed[] = {"S100", "S200", "S400", "S800"}; tmap = malloc(sizeof(struct fw_topology_map)); if (tmap == NULL) - return; + err(EX_SOFTWARE, "%s:tmap malloc", __func__); if (ioctl(fd, FW_GTPMAP, tmap) < 0) { - err(1, "ioctl"); + err(EX_IOERR, "%s: ioctl", __func__); } printf("crc_len: %d generation:%d node_count:%d sid_count:%d\n", tmap->crc_len, tmap->generation, @@ -512,7 +536,7 @@ for (i = 0; i < len; i++) { reg.addr = offset + i; if (ioctl(fd, FWOHCI_RDPHYREG, ®) < 0) - err(1, "ioctl"); + err(EX_IOERR, "%s: ioctl", __func__); buf[i] = (u_int8_t) reg.data; printf("0x%02x ", reg.data); } @@ -527,7 +551,7 @@ reg.addr = 0x7; reg.data = ((page & 7) << 5) | (port & 0xf); if (ioctl(fd, FWOHCI_WRPHYREG, ®) < 0) - err(1, "ioctl"); + err(EX_IOERR, "%s: ioctl", __func__); read_phy_registers(fd, buf, 8, 8); } @@ -590,22 +614,16 @@ ); } -static void -open_dev(int *fd, char *devbase) +static int +open_dev(int *fd, char *devname) { - char name[256]; - int i; - if (*fd < 0) { - for (i = 0; i < 4; i++) { - snprintf(name, sizeof(name), "%s.%d", devbase, i); - if ((*fd = open(name, O_RDWR)) >= 0) - break; - } + *fd = open(devname, O_RDWR); if (*fd < 0) - err(1, "open"); + return(-1); } + return(0); } static void @@ -625,25 +643,40 @@ u_int32_t *ptr; struct ciphdr *ciph; fwmethod *retfn; +#define RECV_NUM_PACKET 16 +#define RECV_PACKET_SZ 1024 bufreq.rx.nchunk = 8; - bufreq.rx.npacket = 16; - bufreq.rx.psize = 1024; + bufreq.rx.npacket = RECV_NUM_PACKET; + bufreq.rx.psize = RECV_PACKET_SZ; bufreq.tx.nchunk = 0; bufreq.tx.npacket = 0; bufreq.tx.psize = 0; if (ioctl(fd, FW_SSTBUF, &bufreq) < 0) - err(1, "ioctl FW_SSTBUF"); + err(EX_IOERR, "%s: ioctl FW_SSTBUF", __func__); isoreq.ch = ich & 0x3f; isoreq.tag = (ich >> 6) & 3; if (ioctl(fd, FW_SRSTREAM, &isoreq) < 0) - err(1, "ioctl FW_SRSTREAM"); + err(EX_IOERR, "%s: ioctl FW_SRSTREAM", __func__); - buf = (char *)malloc(1024*16); - len = read(fd, buf, 1024*16); + buf = (char *)malloc(RECV_NUM_PACKET * RECV_PACKET_SZ); + if (buf == NULL) + err(EX_SOFTWARE, "%s:buf malloc", __func__); + /* + * fwdev.c seems to return EIO on error and + * the return value of the last uiomove + * on success. For now, checking that the + * return is not less than zero should be + * sufficient. fwdev.c::fw_read() should + * return the total length read, not the value + * of the last uiomove(). + */ + len = read(fd, buf, RECV_NUM_PACKET * RECV_PACKET_SZ); + if (len < 0) + err(EX_IOERR, "%s: error reading from device\n", __func__); ptr = (u_int32_t *) buf; ciph = (struct ciphdr *)(ptr + 1); @@ -666,102 +699,167 @@ int main(int argc, char **argv) { +#define MAX_BOARDS 10 u_int32_t crom_buf[1024/4]; - char devbase[1024] = "/dev/fw0"; - int fd, ch, len=1024; + u_int32_t crom_buf_hex[1024/4]; + char devbase[64]; + const char *device_string = "/dev/fw"; + int fd = -1, ch, len=1024; + int32_t current_board = 0; + /* + * If !command_set, then -u will display the nodes for the board. + * This emulates the previous behavior when -u is passed by itself + */ + bool command_set = false; + bool open_needed = false; long tmp; struct fw_eui64 eui; struct eui64 target; fwmethod *recvfn = NULL; +/* + * Holders for which functions + * to iterate through + */ + bool display_board_only = false; + bool display_crom = false; + bool send_bus_reset = false; + bool display_crom_hex = false; + bool load_crom_from_file = false; + bool set_fwmem_target = false; + bool dump_topology = false; + bool dump_phy_reg = false; - fd = -1; + int32_t priority_budget = -1; + int32_t adjust_gap_count = -1; + int32_t reset_gap_count = -1; + int32_t send_link_on = -1; + int32_t send_reset_start = -1; + char *crom_string = NULL; + char *crom_string_hex = NULL; + char *recv_data = NULL; + char *send_data = NULL; + if (argc < 2) { - open_dev(&fd, devbase); - list_dev(fd); + for (current_board = 0; current_board < MAX_BOARDS; current_board++) { + snprintf(devbase, sizeof(devbase), "%s%d", device_string, current_board); + if (open_dev(&fd, devbase) < 0) { + if (current_board == 0) { + usage(); + } + return(EIO); + } + list_dev(fd); + close(fd); + fd = -1; + } } - - while ((ch = getopt(argc, argv, "M:f:g:m:o:s:b:prtc:d:l:u:R:S:")) != -1) + /* + * Parse all command line options, then execute requested operations. + */ + while ((ch = getopt(argc, argv, "M:f:g:m:o:s:b:prtc:d:l:u:R:S:")) != -1) { switch(ch) { case 'b': - tmp = strtol(optarg, NULL, 0); - if (tmp < 0 || tmp > (long)0xffffffff) - errx(EX_USAGE, "invalid number: %s", optarg); - open_dev(&fd, devbase); - set_pri_req(fd, tmp); + priority_budget = strtol(optarg, NULL, 0); + if (priority_budget < 0 || priority_budget > INT32_MAX) + errx(EX_USAGE, "%s: invalid number: %s", __func__, optarg); + command_set = true; + open_needed = true; + display_board_only = false; break; case 'c': - open_dev(&fd, devbase); - tmp = str2node(fd, optarg); - get_crom(fd, tmp, crom_buf, len); - show_crom(crom_buf); + crom_string = malloc(strlen(optarg)+1); + if (crom_string == NULL) + err(EX_SOFTWARE, "%s:crom_string malloc", __func__); + if ( (strtol(crom_string, NULL, 0) < 0) || strtol(crom_string, NULL, 0) > MAX_BOARDS) + err(EX_USAGE, "%s:Invalid value for node", __func__); + strcpy(crom_string, optarg); + display_crom = 1; + open_needed = true; + command_set = true; + display_board_only = false; break; case 'd': - open_dev(&fd, devbase); - tmp = str2node(fd, optarg); - get_crom(fd, tmp, crom_buf, len); - dump_crom(crom_buf); + crom_string_hex = malloc(strlen(optarg)+1); + if (crom_string_hex == NULL) + err(EX_SOFTWARE, "%s:crom_string_hex malloc", __func__); + strcpy(crom_string_hex, optarg); + display_crom_hex = 1; + open_needed = true; + command_set = true; + display_board_only = false; break; case 'f': - tmp = strtol(optarg, NULL, 0); - open_dev(&fd, devbase); - send_phy_config(fd, tmp, -1); + adjust_gap_count = strtol(optarg, NULL, 0); + if ( (adjust_gap_count < 0) || (adjust_gap_count > INT32_MAX) ) + err(EX_USAGE, "%s:adjust_gap_count out of range", __func__); + open_needed = true; + command_set = true; + display_board_only = false; break; case 'g': - tmp = strtol(optarg, NULL, 0); - open_dev(&fd, devbase); - send_phy_config(fd, -1, tmp); + reset_gap_count = strtol(optarg, NULL, 0); + if ( (reset_gap_count < 0) || (reset_gap_count > INT32_MAX) ) + err(EX_USAGE, "%s:reset_gap_count out of range", __func__); + open_needed = true; + command_set = true; + display_board_only = false; break; case 'l': + load_crom_from_file = 1; load_crom(optarg, crom_buf); - show_crom(crom_buf); + command_set = true; + display_board_only = false; break; case 'm': - if (eui64_hostton(optarg, &target) != 0 && - eui64_aton(optarg, &target) != 0) - errx(EX_USAGE, "invalid target: %s", optarg); - eui.hi = ntohl(*(u_int32_t*)&(target.octet[0])); - eui.lo = ntohl(*(u_int32_t*)&(target.octet[4])); - sysctl_set_int("hw.firewire.fwmem.eui64_hi", eui.hi); - sysctl_set_int("hw.firewire.fwmem.eui64_lo", eui.lo); + set_fwmem_target = 1; + open_needed = 0; + command_set = true; + display_board_only = false; + if (eui64_hostton(optarg, &target) != 0 && + eui64_aton(optarg, &target) != 0) + err(EX_USAGE, "%s: invalid target: %s", __func__, optarg); break; case 'o': - open_dev(&fd, devbase); - tmp = str2node(fd, optarg); - send_link_on(fd, tmp); + send_link_on = str2node(fd, optarg); + if ( (send_link_on < 0) || (send_link_on > INT32_MAX) ) + err(EX_USAGE, "%s: node out of range: %s\n",__func__, optarg); + open_needed = true; + command_set = true; + display_board_only = false; break; case 'p': - open_dev(&fd, devbase); - dump_phy_registers(fd); + dump_phy_reg = 1; + open_needed = true; + command_set = true; + display_board_only = false; break; case 'r': - open_dev(&fd, devbase); - if(ioctl(fd, FW_IBUSRST, &tmp) < 0) - err(1, "ioctl"); + send_bus_reset = 1; + open_needed = true; + command_set = true; + display_board_only = false; break; case 's': - open_dev(&fd, devbase); - tmp = str2node(fd, optarg); - reset_start(fd, tmp); + send_reset_start = str2node(fd, optarg); + if ( (send_reset_start < 0) || (send_reset_start > INT32_MAX) ) + err(EX_USAGE, "%s: node out of range: %s\n", __func__, optarg); + open_needed = true; + command_set = true; + display_board_only = false; break; case 't': - open_dev(&fd, devbase); - show_topology_map(fd); + dump_topology = 1; + open_needed = true; + command_set = true; + display_board_only = false; break; case 'u': - tmp = strtol(optarg, NULL, 0); - snprintf(devbase, sizeof(devbase), "/dev/fw%ld", tmp); - if (fd > 0) { - close(fd); - fd = -1; - } - if (argc == optind) { - open_dev(&fd, devbase); - list_dev(fd); - } + if(!command_set) + display_board_only = true; + current_board = strtol(optarg, NULL, 0); + open_needed = true; break; -#define TAG (1<<6) -#define CHANNEL 63 case 'M': switch (optarg[0]) { case 'm': @@ -774,22 +872,164 @@ errx(EX_USAGE, "unrecognized method: %s", optarg); } + command_set = true; + display_board_only = false; break; case 'R': - open_dev(&fd, devbase); - if (recvfn == NULL) /* guess... */ - recvfn = detect_recv_fn(fd, TAG | CHANNEL); - close(fd); - fd = -1; - open_dev(&fd, devbase); - (*recvfn)(fd, optarg, TAG | CHANNEL, -1); + recv_data = malloc(strlen(optarg)+1); + if (recv_data == NULL) + err(EX_SOFTWARE, "%s:recv_data malloc", __func__); + strcpy(recv_data, optarg); + open_needed = false; + command_set = true; + display_board_only = false; break; case 'S': - open_dev(&fd, devbase); - dvsend(fd, optarg, TAG | CHANNEL, -1); + send_data = malloc(strlen(optarg)+1); + if (send_data == NULL) + err(EX_SOFTWARE, "%s:send_data malloc", __func__); + strcpy(send_data, optarg); + open_needed = true; + command_set = true; + display_board_only = false; break; default: usage(); + return 0; } + } /* end while */ + + /* + * If -u is passed, execute + * command for that card only. + * + * If -u is not passed, execute + * command for card 0 only. + * + */ + if(open_needed){ + snprintf(devbase, sizeof(devbase), "%s%d", device_string, current_board); + if (open_dev(&fd, devbase) < 0) { + errx(EX_IOERR, "%s: Error opening board #%d\n", __func__, current_board); + } + } + /* + * display the nodes on this board "-u" + * only + */ + if (display_board_only) + list_dev(fd); + + /* + * dump_phy_reg "-p" + */ + if (dump_phy_reg) + dump_phy_registers(fd); + + /* + * send a BUS_RESET Event "-r" + */ + if (send_bus_reset) { + if(ioctl(fd, FW_IBUSRST, &tmp) < 0) + err(EX_IOERR, "%s: ioctl", __func__); + } + /* + * Print out the CROM for this node "-c" + */ + if (display_crom) { + tmp = str2node(fd, crom_string); + get_crom(fd, tmp, crom_buf, len); + show_crom(crom_buf); + free(crom_string); + } + /* + * Hex Dump the CROM for this node "-d" + */ + if (display_crom_hex) { + tmp = str2node(fd, crom_string_hex); + get_crom(fd, tmp, crom_buf_hex, len); + dump_crom(crom_buf_hex); + free(crom_string_hex); + } + /* + * Set Priority Budget to value for this node "-b" + */ + if (priority_budget >= 0) + set_pri_req(fd, priority_budget); + + /* + * Adjust the gap count for this card/bus to value "-f" + */ + if (adjust_gap_count >= 0) + send_phy_config(fd, adjust_gap_count, -1); + + /* + * Reset the gap count for this card/bus "-g" + */ + if (reset_gap_count >= 0) + send_phy_config(fd, -1, reset_gap_count); + + /* + * Load a CROM from a file "-l" + */ + if (load_crom_from_file) + show_crom(crom_buf); + /* + * Set the fwmem target for a node to argument "-m" + */ + if (set_fwmem_target) { + eui.hi = ntohl(*(u_int32_t*)&(target.octet[0])); + eui.lo = ntohl(*(u_int32_t*)&(target.octet[4])); + sysctl_set_int("hw.firewire.fwmem.eui64_hi", eui.hi); + sysctl_set_int("hw.firewire.fwmem.eui64_lo", eui.lo); + } + + /* + * Send a link on to this board/bus "-o" + */ + if (send_link_on >= 0) + link_on(fd, send_link_on); + + /* + * Send a reset start to this board/bus "-s" + */ + if (send_reset_start >= 0) + reset_start(fd, send_reset_start); + + /* + * Dump the node topology for this board/bus "-t" + */ + if (dump_topology) + show_topology_map(fd); + + /* + * Recieve data file from node "-R" + */ +#define TAG (1<<6) +#define CHANNEL 63 + if (recv_data != NULL){ + if (recvfn == NULL) { /* guess... */ + recvfn = detect_recv_fn(fd, TAG | CHANNEL); + close(fd); + } + snprintf(devbase, sizeof(devbase), "%s%d", device_string, current_board); + if (open_dev(&fd, devbase) < 0) + errx(EX_IOERR, "%s: Error opening board #%d in recv_data\n", __func__, current_board); + (*recvfn)(fd, recv_data, TAG | CHANNEL, -1); + free(recv_data); + } + + /* + * Send data file to node "-S" + */ + if (send_data != NULL){ + dvsend(fd, send_data, TAG | CHANNEL, -1); + free(send_data); + } + + if (fd > 0) { + close(fd); + fd = -1; + } return 0; } From freebsd at sopwith.solgatos.com Tue Aug 19 02:14:58 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Tue Aug 19 02:15:04 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: Your message of "Mon, 18 Aug 2008 17:02:56 PDT." <48AA0DB0.2020306@miralink.com> Message-ID: <200808190213.CAA20684@sopwith.solgatos.com> I tried rebooting again, and then powered up the camera and pressed play. Without running fwcontrol at all. The console spewed away. Just to be explicit, it didn't do this until today. So I think the kernel device driver needs to reset and/or initialize something, probably on the fw controller chip. Thoughts? From sbruno at miralink.com Tue Aug 19 02:25:32 2008 From: sbruno at miralink.com (Sean Bruno) Date: Tue Aug 19 02:25:38 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: <200808190213.CAA20684@sopwith.solgatos.com> References: <200808190213.CAA20684@sopwith.solgatos.com> Message-ID: <48AA2F1A.9040306@miralink.com> Dieter wrote: > I tried rebooting again, and then powered up the camera > and pressed play. Without running fwcontrol at all. > The console spewed away. > > Just to be explicit, it didn't do this until today. > > So I think the kernel device driver needs to reset and/or > initialize something, probably on the fw controller chip. > Thoughts? > Ok, good times. Can you post the output of "fwcontrol -p" for me? -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Cell 503-358-6832 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com From sbruno at miralink.com Tue Aug 19 04:00:29 2008 From: sbruno at miralink.com (Sean Bruno) Date: Tue Aug 19 04:00:40 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: <48AA2F1A.9040306@miralink.com> References: <200808190213.CAA20684@sopwith.solgatos.com> <48AA2F1A.9040306@miralink.com> Message-ID: <48AA4543.1040404@miralink.com> Sean Bruno wrote: > Dieter wrote: >> I tried rebooting again, and then powered up the camera >> and pressed play. Without running fwcontrol at all. >> The console spewed away. >> >> Just to be explicit, it didn't do this until today. >> >> So I think the kernel device driver needs to reset and/or >> initialize something, probably on the fw controller chip. >> Thoughts? >> > Ok, good times. > Can you post the output of "fwcontrol -p" for me? > Looking over the driver code, I can't see any clear path from what malfunctioned to the errors you are seeing now. I would think that a simple bus reset from fwcontrol would clear this. The BUSRST message means that the driver is getting a BUS_RESET when it's internal state machine is not BUS_RESET. Kind of confusing, but that means you should be able to clear it out with a "fwcontrol -r -u 1" ??? You will _HAVE_ to use the new code to send a bus reset to the second bus. -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Cell 503-358-6832 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com From freebsd at sopwith.solgatos.com Tue Aug 19 05:57:13 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Tue Aug 19 05:57:20 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: Your message of "Mon, 18 Aug 2008 19:25:30 PDT." <48AA2F1A.9040306@miralink.com> Message-ID: <200808190555.FAA25963@sopwith.solgatos.com> > > I tried rebooting again, and then powered up the camera > > and pressed play. Without running fwcontrol at all. > > The console spewed away. > > > > Just to be explicit, it didn't do this until today. > > > > So I think the kernel device driver needs to reset and/or > > initialize something, probably on the fw controller chip. > > Thoughts? > > Ok, good times. > > Can you post the output of "fwcontrol -p" for me? fwcontrol -u 0 -p ( for comparison ) === base register === 0x03 0x05 0xe2 0x40 0xc1 0x03 0x00 0x20 Physical_ID:0 R:1 CPS:1 RHB:0 IBR:0 Gap_Count:5 Extended:7 Num_Ports:2 PHY_Speed:2 Delay:0 LCtrl:1 C:1 Jitter:0 Pwr_Class:1 WDIE:0 ISBR:0 CTOI:0 CPSI:0 STOI:0 PEI:0 EAA:1 EMC:1 Max_Legacy_SPD:0 BLINK:0 Bridge:0 Page_Select:1 Port_Select0 === page 0 port 0 === 0x08 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Astat:0 BStat:0 Ch:1 Con:0 RXOK:0 Dis:0 Negotiated_speed:0 PIE:0 Fault:0 Stanby_fault:0 Disscrm:0 B_Only:0 DC_connected:0 Max_port_speed:0 LPP:0 Cable_speed:0 Connection_unreliable:0 Beta_mode:0 Port_error:0x0 Loop_disable:0 In_standby:0 Hard_disable:0 === page 0 port 1 === 0x08 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Astat:0 BStat:0 Ch:1 Con:0 RXOK:0 Dis:0 Negotiated_speed:0 PIE:0 Fault:0 Stanby_fault:0 Disscrm:0 B_Only:0 DC_connected:0 Max_port_speed:0 LPP:0 Cable_speed:0 Connection_unreliable:0 Beta_mode:0 Port_error:0x0 Loop_disable:0 In_standby:0 Hard_disable:0 === page 1 === 0x01 0x00 0x00 0x11 0x63 0x30 0x60 0x01 Compliance:1 Vendor_ID:0x001163 Product_ID:0x306001 fwcontrol -u 1 -p (the bus actually in use) === base register === 0x06 0x85 0xe2 0x42 0xd7 0x03 0x00 0x20 Physical_ID:1 R:1 CPS:0 RHB:1 IBR:0 Gap_Count:5 Extended:7 Num_Ports:2 PHY_Speed:2 Delay:2 LCtrl:1 C:1 Jitter:2 Pwr_Class:7 WDIE:0 ISBR:0 CTOI:0 CPSI:0 STOI:0 PEI:0 EAA:1 EMC:1 Max_Legacy_SPD:0 BLINK:0 Bridge:0 Page_Select:1 Port_Select0 === page 0 port 0 === 0x08 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Astat:0 BStat:0 Ch:1 Con:0 RXOK:0 Dis:0 Negotiated_speed:0 PIE:0 Fault:0 Stanby_fault:0 Disscrm:0 B_Only:0 DC_connected:0 Max_port_speed:0 LPP:0 Cable_speed:0 Connection_unreliable:0 Beta_mode:0 Port_error:0x0 Loop_disable:0 In_standby:0 Hard_disable:0 === page 0 port 1 === 0xfe 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Astat:3 BStat:3 Ch:1 Con:1 RXOK:1 Dis:0 Negotiated_speed:0 PIE:0 Fault:0 Stanby_fault:0 Disscrm:0 B_Only:0 DC_connected:0 Max_port_speed:0 LPP:0 Cable_speed:0 Connection_unreliable:0 Beta_mode:0 Port_error:0x0 Loop_disable:0 In_standby:0 Hard_disable:0 === page 1 === 0x01 0x00 0x00 0x00 0x4c 0x02 0x00 0x00 Compliance:1 Vendor_ID:0x00004c Product_ID:0x020000 And while we're at it: fwcontrol -u 0 -t crc_len: 3 generation:1 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 15W - - 1 0 fwcontrol -u 1 -t crc_len: 4 generation:8 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 > I would think that a simple bus reset from fwcontrol would clear this. So I clear a bus reset with a bus reset. Like fighting fire(wire) with fire(wire). :-) It may clear something, but when I press play it starts again. > The BUSRST message means that the driver > is getting a BUS_RESET when it's internal state machine is not > BUS_RESET. Ok, but why is it getting all these BUS_RESETs? DV data arrives from the camera and all these BUS_RESETs happen. Hundreds of them, the gen number wraps around. > Kind of confusing, but that means > you should be able to clear it out with a "fwcontrol -r -u 1" ??? You > will _HAVE_ to use the new code to send a bus reset > to the second bus. The prev version is able to reset the bus. Prev version is dated Mar 5, file(1) doesn't say "for FreeBSD 7.0" like it does on the recent ones, so it would be from 6.2, adding the -f option to force "non CYCLEMASTER mode" (see PR kern/113785). fwcontrol -u 1 -f 0 fwcontrol -u 1 -r IIRC, the prev version is picky about the order of the arguments, (-u 1 needs to be first) but it does reset the bus. From freebsd at sopwith.solgatos.com Tue Aug 19 06:23:45 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Tue Aug 19 06:23:51 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: Your message of "Mon, 18 Aug 2008 15:27:01 PDT." <48A9F735.5090507@miralink.com> Message-ID: <200808190622.GAA18270@sopwith.solgatos.com> > > I notice that it doesn't print every generation. > > I notice that the node_id changes. > > > This alarms me quite a bit. I didn't think there was anyway for the > generation to change > without the log message being spit out. Interesting. Perhaps there is some register on the controller chip that affects receiving data but not sending it, and isn't getting initialized. Perhaps the controller chip thinks it is receiving bad data, and flags an error or requests a bus reset? If the resets are happening faster than the printf can run, maybe the data (generation number) changes underneath the printf, much like ps/top don't get a pure snapshot? From sbruno at miralink.com Wed Aug 20 00:11:02 2008 From: sbruno at miralink.com (Sean Bruno) Date: Wed Aug 20 00:11:08 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: <200808190622.GAA18270@sopwith.solgatos.com> References: <200808190622.GAA18270@sopwith.solgatos.com> Message-ID: <48AB6115.6090308@miralink.com> Dieter wrote: >>> I notice that it doesn't print every generation. >>> I notice that the node_id changes. >>> >> This alarms me quite a bit. I didn't think there was anyway for the >> generation to change >> without the log message being spit out. Interesting. >> > > Perhaps there is some register on the controller chip that > affects receiving data but not sending it, and isn't getting > initialized. Perhaps the controller chip thinks it is receiving > bad data, and flags an error or requests a bus reset? > > If the resets are happening faster than the printf can run, > maybe the data (generation number) changes underneath the printf, > much like ps/top don't get a pure snapshot? > Hrm...First, let's try and get your camera working again. I would like you to try and connect your camera to a Mac, Linux or Windows box and try to get it working again. Sean -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com From freebsd at sopwith.solgatos.com Wed Aug 20 06:08:24 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Wed Aug 20 06:08:30 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: Your message of "Tue, 19 Aug 2008 17:11:01 PDT." <48AB6115.6090308@miralink.com> Message-ID: <200808200607.GAA01246@sopwith.solgatos.com> > >>> I notice that it doesn't print every generation. > >>> I notice that the node_id changes. > >>> > >> This alarms me quite a bit. I didn't think there was anyway for the > >> generation to change > >> without the log message being spit out. Interesting. > >> > > > > Perhaps there is some register on the controller chip that > > affects receiving data but not sending it, and isn't getting > > initialized. Perhaps the controller chip thinks it is receiving > > bad data, and flags an error or requests a bus reset? > > > > If the resets are happening faster than the printf can run, > > maybe the data (generation number) changes underneath the printf, > > much like ps/top don't get a pure snapshot? > > > Hrm...First, let's try and get your camera working again. > > I would like you to try and connect your camera to a Mac, Linux or > Windows box and try to get it working again. As far as I can tell the camera is working fine. For example I can send DV data *to* the camera over firewire and it happily converts it to analog and ships it out s-video to the TV. And the data *from* the camera is recognized as DV: fwcontrol_prev -u 1 -R camera.dv Detected DV format on input. (EAGAIN) (EAGAIN) (EAGAIN) The camera was of course powered off while I tested the argument range checks. And I only ran tests that seemed safe. I'm not *completely* insane. From sbruno at miralink.com Wed Aug 20 16:56:06 2008 From: sbruno at miralink.com (Sean Bruno) Date: Wed Aug 20 16:56:14 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: <200808200607.GAA01246@sopwith.solgatos.com> References: <200808200607.GAA01246@sopwith.solgatos.com> Message-ID: <48AC4CA2.2080801@miralink.com> Dieter wrote: >>>>> I notice that it doesn't print every generation. >>>>> I notice that the node_id changes. >>>>> >>>>> >>>> This alarms me quite a bit. I didn't think there was anyway for the >>>> generation to change >>>> without the log message being spit out. Interesting. >>>> >>>> >>> Perhaps there is some register on the controller chip that >>> affects receiving data but not sending it, and isn't getting >>> initialized. Perhaps the controller chip thinks it is receiving >>> bad data, and flags an error or requests a bus reset? >>> >>> If the resets are happening faster than the printf can run, >>> maybe the data (generation number) changes underneath the printf, >>> much like ps/top don't get a pure snapshot? >>> >>> >> Hrm...First, let's try and get your camera working again. >> >> I would like you to try and connect your camera to a Mac, Linux or >> Windows box and try to get it working again. >> > > As far as I can tell the camera is working fine. > > For example I can send DV data *to* the camera over firewire and it > happily converts it to analog and ships it out s-video to the TV. > > And the data *from* the camera is recognized as DV: > > fwcontrol_prev -u 1 -R camera.dv > Detected DV format on input. > (EAGAIN) > (EAGAIN) > (EAGAIN) > > The camera was of course powered off while I tested the argument > range checks. And I only ran tests that seemed safe. I'm not > *completely* insane. > So, is you camera working perfectly at this time? I.e. with old fwcontrol, everything is fine? My concern was that somehow we had triggered a bit in the firewire hardware(most likely the camera) that caused you camera to be non-functional. -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com From freebsd at sopwith.solgatos.com Wed Aug 20 17:37:59 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Wed Aug 20 17:38:06 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: Your message of "Wed, 20 Aug 2008 09:56:02 PDT." <48AC4CA2.2080801@miralink.com> Message-ID: <200808201736.RAA06706@sopwith.solgatos.com> > >>>>> I notice that it doesn't print every generation. > >>>>> I notice that the node_id changes. > >>>>> > >>>>> > >>>> This alarms me quite a bit. I didn't think there was anyway for the > >>>> generation to change > >>>> without the log message being spit out. Interesting. > >>>> > >>>> > >>> Perhaps there is some register on the controller chip that > >>> affects receiving data but not sending it, and isn't getting > >>> initialized. Perhaps the controller chip thinks it is receiving > >>> bad data, and flags an error or requests a bus reset? > >>> > >>> If the resets are happening faster than the printf can run, > >>> maybe the data (generation number) changes underneath the printf, > >>> much like ps/top don't get a pure snapshot? > >>> > >>> > >> Hrm...First, let's try and get your camera working again. > >> > >> I would like you to try and connect your camera to a Mac, Linux or > >> Windows box and try to get it working again. > >> > > > > As far as I can tell the camera is working fine. > > > > For example I can send DV data *to* the camera over firewire and it > > happily converts it to analog and ships it out s-video to the TV. > > > > And the data *from* the camera is recognized as DV: > > > > fwcontrol_prev -u 1 -R camera.dv > > Detected DV format on input. > > (EAGAIN) > > (EAGAIN) > > (EAGAIN) > > > > The camera was of course powered off while I tested the argument > > range checks. And I only ran tests that seemed safe. I'm not > > *completely* insane. > > > So, is you camera working perfectly at this time? I.e. with old > fwcontrol, everything is fine? My concern was that somehow we had > triggered a bit in the firewire hardware(most likely the camera) that > caused you camera to be non-functional. I think the camera itself is working. I think the NEC fw controller in the FreeBSD box is slightly messed up, resulting in lots of bus resets when the camera sends DV data. I'll try the VIA fw controller and see if -R works. If it works, then we know the camera is fine. Unfortunately I don't know if -R ever worked with the VIA. -S definitely doesn't work properly with VIA. I haven't been able to get the VIA to go into "non CYCLEMASTER mode", even using the -f option that works with the NEC. From freebsd at sopwith.solgatos.com Wed Aug 20 23:56:13 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Wed Aug 20 23:56:20 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: Your message of "Wed, 20 Aug 2008 09:56:02 PDT." <48AC4CA2.2080801@miralink.com> Message-ID: <200808202354.XAA00211@sopwith.solgatos.com> >> So, is you camera working perfectly at this time? I.e. with old >> fwcontrol, everything is fine? My concern was that somehow we had >> triggered a bit in the firewire hardware(most likely the camera) that >> caused you camera to be non-functional. > > I think the camera itself is working. > > I think the NEC fw controller in the FreeBSD box is slightly messed up, > resulting in lots of bus resets when the camera sends DV data. > > I'll try the VIA fw controller and see if -R works. If it works, > then we know the camera is fine. Unfortunately I don't know if > -R ever worked with the VIA. -S definitely doesn't work properly > with VIA. I haven't been able to get the VIA to go into > "non CYCLEMASTER mode", even using the -f option that works with > the NEC. I moved the cable from the NEC port (bus 1) to the VIA port (bus 0) # fwcontrol -u 0 -f 0 send phy_config root_node=0 gap_count=-1 console says: nothing # fwcontrol -u 0 -r console says: fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc1, gen=5, CYCLEMASTER mode <-- should be non-CYCLEMASTER mode? :-( firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me) firewire0: bus manager 1 (me) # fwcontrol -u 0 -t crc_len: 4 generation:5 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 # fwcontrol -u 0 -R camera.dv Detected DV format on input. NTSC 012345678901234567890123456789 012345678901234567890123456789 012345678901234567890123456789 console says: nothing I then powered down the camera, moved the cable back to the NEC port, powered up, put the NEC into non-CYCLEMASTER mode, ran fwcontrol -S and the DV file played fine. So: the camera itself works fine, and the VIA controller can do -R even in CYCLEMASTER mode. So I'm back to my theory that the NEC controller is slightly unhappy. But what I'd really like, is a way to get the onboard VIA VT6307 controller to do fwcontrol -S correctly. The NEC controller card is using up a slot I need for other things. From sbruno at miralink.com Thu Aug 21 00:01:15 2008 From: sbruno at miralink.com (Sean Bruno) Date: Thu Aug 21 00:01:26 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: <200808202354.XAA00211@sopwith.solgatos.com> References: <200808202354.XAA00211@sopwith.solgatos.com> Message-ID: <48ACB04A.4000009@miralink.com> > I moved the cable from the NEC port (bus 1) to the VIA port (bus 0) > > # fwcontrol -u 0 -f 0 > send phy_config root_node=0 gap_count=-1 > > console says: nothing > > # fwcontrol -u 0 -r > > console says: > > fwohci0: Initiate bus reset > fwohci0: BUS reset > fwohci0: node_id=0xc800ffc1, gen=5, CYCLEMASTER mode <-- should be non-CYCLEMASTER mode? :-( > firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me) > firewire0: bus manager 1 (me) > > # fwcontrol -u 0 -t > crc_len: 4 generation:5 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 > > # fwcontrol -u 0 -R camera.dv > Detected DV format on input. > NTSC > 012345678901234567890123456789 > 012345678901234567890123456789 > 012345678901234567890123456789 > > console says: nothing > > I then powered down the camera, moved the cable back to the > NEC port, powered up, put the NEC into non-CYCLEMASTER mode, > ran fwcontrol -S and the DV file played fine. So: the camera > itself works fine, and the VIA controller can do -R even in > CYCLEMASTER mode. > > So I'm back to my theory that the NEC controller is slightly unhappy. > But what I'd really like, is a way to get the onboard VIA VT6307 controller > to do fwcontrol -S correctly. The NEC controller card is using up a slot > I need for other things. > So your current status is: Camera works with VIA controller. Camera still doesn't work with NEC controller. 1. Does the camera work with the unpatched version of fwcontrol and the NEC controller? 2. The NEC controller is a PCI card. Does anything else work with the NEC controller(external HD?). 3. Is there a bug reported on your VIA VT6307? -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com From freebsd at sopwith.solgatos.com Thu Aug 21 02:10:11 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Thu Aug 21 02:10:17 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: Your message of "Wed, 20 Aug 2008 17:01:14 PDT." <48ACB04A.4000009@miralink.com> Message-ID: <200808210208.CAA00979@sopwith.solgatos.com> > > I moved the cable from the NEC port (bus 1) to the VIA port (bus 0) > > > > # fwcontrol -u 0 -f 0 > > send phy_config root_node=0 gap_count=-1 > > > > console says: nothing > > > > # fwcontrol -u 0 -r > > > > console says: > > > > fwohci0: Initiate bus reset > > fwohci0: BUS reset > > fwohci0: node_id=0xc800ffc1, gen=5, CYCLEMASTER mode <-- should be non-CYCLEMASTER mode? :-( > > firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me) > > firewire0: bus manager 1 (me) > > > > # fwcontrol -u 0 -t > > crc_len: 4 generation:5 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 > > > > # fwcontrol -u 0 -R camera.dv > > Detected DV format on input. > > NTSC > > 012345678901234567890123456789 > > 012345678901234567890123456789 > > 012345678901234567890123456789 > > > > console says: nothing > > > > I then powered down the camera, moved the cable back to the > > NEC port, powered up, put the NEC into non-CYCLEMASTER mode, > > ran fwcontrol -S and the DV file played fine. So: the camera > > itself works fine, and the VIA controller can do -R even in > > CYCLEMASTER mode. > > > > So I'm back to my theory that the NEC controller is slightly unhappy. > > But what I'd really like, is a way to get the onboard VIA VT6307 controller > > to do fwcontrol -S correctly. The NEC controller card is using up a slot > > I need for other things. > > > So your current status is: Camera works with VIA controller. Camera > still doesn't work with NEC controller. More accurately: the camera itself works VIA controller can do fwcontrol -R VIA controller attempting to do fwcontrol -S gives dropouts on a regular basis, every couple seconds. NEC does the same thing if in CYCLEMASTER mode. I have not been able to get the VIA into non-CYCLEMASTER mode. See today's attempt to do so using fwcontrol -f above. NEC controller can do fwcontrol -S (after switching to non-CYCLEMASTER mode) NEC controller used to do fwcontrol -R Now, if camera is connected to NEC controller and I press play (sending DV data to computer), lots of bus resets happen. The resets have nothing to do with running fwcontrol. The resets happen even if fwcontrol has not been run at all since FreeBSD was rebooted. > 1. Does the camera work with the unpatched version of fwcontrol and the > NEC controller? NEC controller can do fwcontrol -S (after switching to non-CYCLEMASTER mode) > 2. The NEC controller is a PCI card. yes > Does anything else work with the > NEC controller(external HD?). unknown > 3. Is there a bug reported on your VIA VT6307? yes http://www.FreeBSD.org/cgi/query-pr.cgi?pr=113785&cat=kern If we assume that I need to get the VIA into non-CYCLEMASTER mode, (since that worked with the NEC), any ideas why fwcontrol -u 0 -f 0 fwcontrol -u 0 -r doesn't force the VIA into non-CYCLEMASTER mode the way it (with -u 1) works for NEC? From sbruno at miralink.com Thu Aug 21 03:18:52 2008 From: sbruno at miralink.com (Sean Bruno) Date: Thu Aug 21 03:18:58 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: <200808210208.CAA00979@sopwith.solgatos.com> References: <200808210208.CAA00979@sopwith.solgatos.com> Message-ID: <48ACDE83.1040408@miralink.com> > More accurately: > > the camera itself works > > VIA controller can do fwcontrol -R > > VIA controller attempting to do fwcontrol -S gives dropouts > on a regular basis, every couple seconds. NEC does the same > thing if in CYCLEMASTER mode. I have not been able to get > the VIA into non-CYCLEMASTER mode. See today's attempt to > do so using fwcontrol -f above. > > NEC controller can do fwcontrol -S (after switching to > non-CYCLEMASTER mode) > > NEC controller used to do fwcontrol -R > > Now, if camera is connected to NEC controller and I press play > (sending DV data to computer), lots of bus resets happen. The > resets have nothing to do with running fwcontrol. The resets > happen even if fwcontrol has not been run at all since FreeBSD > was rebooted. > > Thank you for being patient with me as I begin my journey into the firewire stack! So, at this point I have done "something" to the NEC controller to remove functionality. I don't suppose you have a Linux live CD lying around that you can boot up into? My hope, would be that the Linux firewire stack would reset you controller back to a functional state. Then I could work on my original idea of flushing out fwcontrol. I just don't know or understand enough of the firewire driver yet to be able to repair this condition. I'd like to get you back to your original state, and possibly diagnose the failure in the first place. >> 3. Is there a bug reported on your VIA VT6307? >> > > yes > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=113785&cat=kern > > If we assume that I need to get the VIA into non-CYCLEMASTER mode, > (since that worked with the NEC), any ideas why > > fwcontrol -u 0 -f 0 > fwcontrol -u 0 -r > > doesn't force the VIA into non-CYCLEMASTER mode the way > it (with -u 1) works for NEC? > I will review this bug later in the morning and see if I can understand your current implementation. This seems a strange way to use your camera to me ... all of this setting and resetting parameters mess may be higher on my list than I wanted it to be initially. :) -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Cell 503-358-6832 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com From freebsd at sopwith.solgatos.com Thu Aug 21 17:47:20 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Thu Aug 21 17:47:26 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: Your message of "Wed, 20 Aug 2008 20:18:27 PDT." <48ACDE83.1040408@miralink.com> Message-ID: <200808211744.RAA12308@sopwith.solgatos.com> > > More accurately: > > > > the camera itself works > > > > VIA controller can do fwcontrol -R > > > > VIA controller attempting to do fwcontrol -S gives dropouts > > on a regular basis, every couple seconds. NEC does the same > > thing if in CYCLEMASTER mode. I have not been able to get > > the VIA into non-CYCLEMASTER mode. See today's attempt to > > do so using fwcontrol -f above. > > > > NEC controller can do fwcontrol -S (after switching to > > non-CYCLEMASTER mode) > > > > NEC controller used to do fwcontrol -R > > > > Now, if camera is connected to NEC controller and I press play > > (sending DV data to computer), lots of bus resets happen. The > > resets have nothing to do with running fwcontrol. The resets > > happen even if fwcontrol has not been run at all since FreeBSD > > was rebooted. > So, at this point I have done "something" to the NEC controller to > remove functionality. Maybe, maybe not. It might have been fwcontrol, or it might have been putting the camera in "camera" mode instead of "vcr" mode. The previous time I tried that, nothing at all happened. I don't remember which controller it was connected to last time, so it might have been the VIA. The goal being to capture video live, rather than having to record it on tape, rewind, play back. Previously I got no indication that the camera was sending any data to the computer, this time I got the bus reset spewage. I would think that the data would be the same either way (live or tape), but perhaps there is some difference which messed up the NCR. In hindsight, that was a bad time to throw in another variable. :-( I tried booting NetBSD, looks like they ported FreeBSD's firewire over, but an older version without the -f option I need. As you might expect, I get similar spewage from NetBSD: fwohci1: BUS reset fwohci1: node_id=0xc000ffc0, gen=53, CYCLEMASTER mode ieee1394if1: 1 nodes, maxhop <= 0, cable IRM = 0 (me) ieee1394if1: bus manager 0 (me) fwohci1: BUS reset fwohci1: node_id=0xc000ffc1, gen=72, CYCLEMASTER mode ieee1394if1: 2 nodes, maxhop <= 1, cable IRM = 1 (me) ieee1394if1: bus manager 0 ieee1394if1: split transaction timeout dst=0xffc0 tl=0x18 state=3 fwohci1: BUS reset fwohci1: node_id=0xc000ffc0, gen=76, CYCLEMASTER mode ieee1394if1: 1 nodes, maxhop <= 0, cable IRM = 0 (me) ieee1394if1: bus manager 0 (me) fwohci1: BUS reset fwohci1: node_id=0xc000ffc1, gen=103, CYCLEMASTER mode ieee1394if1: 2 nodes, maxhop <= 1, cable IRM = 1 (me) ieee1394if1: bus manager 0 > >> 3. Is there a bug reported on your VIA VT6307? > >> > > > > yes > > > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=113785&cat=kern > > > > If we assume that I need to get the VIA into non-CYCLEMASTER mode, > > (since that worked with the NEC), any ideas why > > > > fwcontrol -u 0 -f 0 > > fwcontrol -u 0 -r > > > > doesn't force the VIA into non-CYCLEMASTER mode the way > > it (with -u 1) works for NEC? > > > > I will review this bug later in the morning and see if I can understand > your current implementation. Thanks. > This seems a strange way to use your camera to me Strange how? From sbruno at miralink.com Thu Aug 21 18:18:56 2008 From: sbruno at miralink.com (Sean Bruno) Date: Thu Aug 21 18:19:03 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: <200808211744.RAA12308@sopwith.solgatos.com> References: <200808211744.RAA12308@sopwith.solgatos.com> Message-ID: <48ADB18F.3000507@miralink.com> Dieter wrote: >>> More accurately: >>> >>> the camera itself works >>> >>> VIA controller can do fwcontrol -R >>> >>> VIA controller attempting to do fwcontrol -S gives dropouts >>> on a regular basis, every couple seconds. NEC does the same >>> thing if in CYCLEMASTER mode. I have not been able to get >>> the VIA into non-CYCLEMASTER mode. See today's attempt to >>> do so using fwcontrol -f above. >>> >>> NEC controller can do fwcontrol -S (after switching to >>> non-CYCLEMASTER mode) >>> >>> NEC controller used to do fwcontrol -R >>> >>> Now, if camera is connected to NEC controller and I press play >>> (sending DV data to computer), lots of bus resets happen. The >>> resets have nothing to do with running fwcontrol. The resets >>> happen even if fwcontrol has not been run at all since FreeBSD >>> was rebooted. >>> > > >> So, at this point I have done "something" to the NEC controller to >> remove functionality. >> > > Maybe, maybe not. It might have been fwcontrol, or it might have > been putting the camera in "camera" mode instead of "vcr" mode. > The previous time I tried that, nothing at all happened. I don't > remember which controller it was connected to last time, so it might > have been the VIA. The goal being to capture video live, rather than > having to record it on tape, rewind, play back. Previously I got > no indication that the camera was sending any data to the computer, > this time I got the bus reset spewage. I would think that the data > would be the same either way (live or tape), but perhaps there is > some difference which messed up the NCR. > > In hindsight, that was a bad time to throw in another variable. :-( > > Ummm...ok. Is the unit in "vcr" mode now when it generates the spewage? Are we worse or better than when we started? :) > > >> This seems a strange way to use your camera to me >> > > Strange how? > It's strange to me that you don't have any applications other than fwcontrol to pull and push files from your camera. -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com From freebsd at sopwith.solgatos.com Thu Aug 21 19:57:26 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Thu Aug 21 19:57:32 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: Your message of "Thu, 21 Aug 2008 11:18:55 PDT." <48ADB18F.3000507@miralink.com> Message-ID: <200808211956.TAA13561@sopwith.solgatos.com> > Ummm...ok. Is the unit in "vcr" mode now when it generates the spewage? Yes, vcr mode. I only tried camera mode twice, once many months ago with 6.x, and once a couple days ago with 7.0. > Are we worse or better than when we started? :) Well... I found a few things in fwcontrol that could use improvement, most of which have been fixed. I found that the NEC appariently isn't getting reset/initialized sufficiently. I found that NetBSD has ported FreeBSD's fw support and thus now works with camcorders. On the other hand if I want to upload data from the camera I now have to move the cable. I still don't know exactly what messed up the NEC, and the VIA still doesn't work properly with -S. > >> This seems a strange way to use your camera to me > >> > > > > Strange how? > > > It's strange to me that you don't have any applications other than fwcontrol > to pull and push files from your camera. I figured cat and dd probably wouldn't work. From sbruno at miralink.com Thu Aug 21 20:35:01 2008 From: sbruno at miralink.com (Sean Bruno) Date: Thu Aug 21 20:35:08 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: <200808211956.TAA13561@sopwith.solgatos.com> References: <200808211956.TAA13561@sopwith.solgatos.com> Message-ID: <48ADD174.90002@miralink.com> Dieter wrote: >> Ummm...ok. Is the unit in "vcr" mode now when it generates the spewage? >> > > Yes, vcr mode. I only tried camera mode twice, once many months ago > with 6.x, and once a couple days ago with 7.0. > > oh...well then. Can you run a live linux distro(unbuntu or knoppix) and see if linux can "reset" your NEC f/w controller? Otherwise, I will be going down a very long and tedious path to try and discover what has broken. This will take me a long time. -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com From freebsd at sopwith.solgatos.com Fri Aug 22 01:28:02 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Fri Aug 22 01:28:08 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: Your message of "Thu, 21 Aug 2008 13:35:00 PDT." <48ADD174.90002@miralink.com> Message-ID: <200808220126.BAA25657@sopwith.solgatos.com> > Can you run a live linux distro(unbuntu or knoppix) and see if linux can > "reset" > your NEC f/w controller? Grumble... If I get penguinix to boot will you look at http://www.freebsd.org/cgi/query-pr.cgi?pr=113785 http://www.freebsd.org/cgi/query-pr.cgi?pr=118093 These two are more problematic than the NEC. > Otherwise, I will be going down a very long and tedious path to try and > discover what has > broken. This will take me a long time. Before you do that... What path are you planning on going down? We don't know what broke it: fwcontrol, camera in camera mode, or something else we haven't thought of. Seems to me that the solution is to look at the datasheet and the device driver and figure out what isn't getting initialized. So we need to find the datasheet for the NEC. From sbruno at miralink.com Fri Aug 22 02:12:41 2008 From: sbruno at miralink.com (Sean Bruno) Date: Fri Aug 22 02:12:52 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: <200808220126.BAA25657@sopwith.solgatos.com> References: <200808220126.BAA25657@sopwith.solgatos.com> Message-ID: <48AE2080.7050409@miralink.com> Dieter wrote: >> Can you run a live linux distro(unbuntu or knoppix) and see if linux can >> "reset" >> your NEC f/w controller? >> > > Grumble... If I get penguinix to boot will you look at > > http://www.freebsd.org/cgi/query-pr.cgi?pr=113785 > http://www.freebsd.org/cgi/query-pr.cgi?pr=118093 > > These two are more problematic than the NEC. > > Cool. It's either that or I consider buying you a new camera? :) >> Otherwise, I will be going down a very long and tedious path to try and >> discover what has >> broken. This will take me a long time. >> > > Before you do that... > > What path are you planning on going down? > We don't know what broke it: fwcontrol, camera in > camera mode, or something else we haven't thought of. > > Seems to me that the solution is to look at the > datasheet and the device driver and figure out what > isn't getting initialized. So we need to find the > datasheet for the NEC. > My current understanding of the firewire stack and fwohci is not very good. I've fixed a few things in my tree(mainly in sbp_targ), but it will take some time for me to fully understand what's going on. We can either get the data sheet off of the NEC or look at what the linux code is doing and attempt a patch to emulate that behavior. -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Cell 503-358-6832 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com From freebsd at sopwith.solgatos.com Fri Aug 22 04:42:06 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Fri Aug 22 04:42:13 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: Your message of "Thu, 21 Aug 2008 18:26:13 BST." Message-ID: <200808220440.EAA09835@sopwith.solgatos.com> > Seems to me that the solution is to look at the > datasheet and the device driver and figure out what > isn't getting initialized. So we need to find the > datasheet for the NEC. http://chipdig.com/datasheets/download_datasheet.php?id=1024801&part-number=UPD72871 345130 bytes 48 page pdf Oddly I didn't find any timing diagrams, but there is a list of registers. Some of them even have descriptions that make sense. And we have useful info like: "VGA color palette invalidate is always disabled." Why a firewire controller would know or care about VGA color palette is beyond me. From freebsd at sopwith.solgatos.com Fri Aug 22 16:43:06 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Fri Aug 22 16:43:13 2008 Subject: VIA VT6307 datasheet Message-ID: <200808221639.QAA21663@sopwith.solgatos.com> http://www.datasheetarchive.com/pdf-datasheets/Datasheets-6/DSA-113181.pdf 453914 bytes 54 pages pdf Questions for firewire wizards: Is "cycle master" the same as "bus master" ? Is "cycle master" the same as being the "root" node ? From bugmaster at FreeBSD.org Mon Aug 25 11:06:49 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 25 11:07:36 2008 Subject: Current problem reports assigned to freebsd-firewire@FreeBSD.org Message-ID: <200808251106.m7PB6ng2027729@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/74238 firewire [firewire] fw_rcv: unknown response; firewire ad-hoc w 1 problem total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/113785 firewire [firewire] dropouts when playing DV on firewire 1 problem total. From freebsd at sopwith.solgatos.com Wed Aug 27 00:33:41 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Wed Aug 27 00:33:47 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: Your message of "Thu, 21 Aug 2008 19:12:16 PDT." <48AE2080.7050409@miralink.com> Message-ID: <200808270031.AAA13884@sopwith.solgatos.com> > >> Can you run a live linux distro(unbuntu or knoppix) and see if linux can > >> "reset" > >> your NEC f/w controller? What does penguinix call firewire? (none):~ # dmesg | grep -i fire (none):~ # dmesg | grep -i fw (none):~ # dmesg | grep -i 1394 (none):~ # dmesg | grep -i link audit: initializing netlink socket (disabled) eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] (none):~ # man -k fire fire: nothing appropriate. (none):~ # man -k fw fw: nothing appropriate. (none):~ # man -k 1394 1394: nothing appropriate. (none):~ # man -k link link: nothing appropriate. Anyway, due to a firmware bug I ended up having to power cycle the machine. (switched off at the P/S, so even 5V standby should have been off) I was expecting the power cycle to completely reset the NEC board. But it is not back to normal. I no longer get the spewage from a constant series of bus resets, but fwcontrol -R still doesn't work. fwcontrol_prev is from March, and used to do -R successfully. fwcontrol_prev -R /dv0/test_prev_camera.dv Detected DV format on input. (EAGAIN) (EAGAIN) (EAGAIN) fwcontrol_prev -u 1 -p === base register === 0x00 0x85 0xe2 0x42 0xd7 0x03 0x00 0x00 Physical_ID:0 R:0 CPS:0 RHB:1 IBR:0 Gap_Count:5 Extended:7 Num_Ports:2 PHY_Speed:2 Delay:2 LCtrl:1 C:1 Jitter:2 Pwr_Class:7 WDIE:0 ISBR:0 CTOI:0 CPSI:0 STOI:0 PEI:0 EAA:1 EMC:1 Max_Legacy_SPD:0 BLINK:0 Bridge:0 Page_Select:0 Port_Select0 === page 0 port 0 === 0x08 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Astat:0 BStat:0 Ch:1 Con:0 RXOK:0 Dis:0 Negotiated_speed:0 PIE:0 Fault:0 Stanby_fault:0 Disscrm:0 B_Only:0 DC_connected:0 Max_port_speed:0 LPP:0 Cable_speed:0 Connection_unreliable:0 Beta_mode:0 Port_error:0x0 Loop_disable:0 In_standby:0 Hard_disable:0 === page 0 port 1 === 0xf6 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Astat:3 BStat:3 Ch:0 Con:1 RXOK:1 Dis:0 Negotiated_speed:0 PIE:0 Fault:0 Stanby_fault:0 Disscrm:0 B_Only:0 DC_connected:0 Max_port_speed:0 LPP:0 Cable_speed:0 Connection_unreliable:0 Beta_mode:0 Port_error:0x0 Loop_disable:0 In_standby:0 Hard_disable:0 === page 1 === 0x01 0x00 0x00 0x00 0x4c 0x02 0x00 0x00 Compliance:1 Vendor_ID:0x00004c Product_ID:0x020000 fwcontrol_prev -u 1 -t crc_len: 4 generation:6 node_count:2 sid_count:2 id link gap_cnt speed delay cIRM power port0 port1 port2 ini more 00 1 5 S400 0 1 -9W - P 1 0 01 1 5 S100 0 1 0W - C 0 0 Now what? From sbruno at miralink.com Wed Aug 27 03:03:40 2008 From: sbruno at miralink.com (Sean Bruno) Date: Wed Aug 27 03:03:46 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: <200808270031.AAA13884@sopwith.solgatos.com> References: <200808270031.AAA13884@sopwith.solgatos.com> Message-ID: <48B4C407.9010900@miralink.com> Dieter wrote: >>>> Can you run a live linux distro(unbuntu or knoppix) and see if linux can >>>> "reset" >>>> your NEC f/w controller? >>>> > > What does penguinix call firewire? > > (none):~ # dmesg | grep -i fire > (none):~ # dmesg | grep -i fw > (none):~ # dmesg | grep -i 1394 > (none):~ # dmesg | grep -i link > audit: initializing netlink socket (disabled) > eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] > > (none):~ # man -k fire > fire: nothing appropriate. > (none):~ # man -k fw > fw: nothing appropriate. > (none):~ # man -k 1394 > 1394: nothing appropriate. > (none):~ # man -k link > link: nothing appropriate. > > I was hoping that you could boot linux, and then plugin your camera and see what the output of dmesg and /var/log/messages has to say. > Anyway, due to a firmware bug I ended up having to power cycle > the machine. (switched off at the P/S, so even 5V standby should > have been off) > > I was expecting the power cycle to completely reset the NEC board. > But it is not back to normal. I no longer get the spewage from a > constant series of bus resets, but fwcontrol -R still doesn't work. > > fwcontrol_prev is from March, and used to do -R successfully. > > fwcontrol_prev -R /dv0/test_prev_camera.dv > Detected DV format on input. > (EAGAIN) > (EAGAIN) > (EAGAIN) > > Is there any chance that you overwrote fwcontrol_prev with my patched version? Could you pull fwcontrol from src and recompile just to check? -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Cell 503-358-6832 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com From freebsd at sopwith.solgatos.com Wed Aug 27 05:46:58 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Wed Aug 27 05:47:05 2008 Subject: Something broke :-( Re: fwcontrol update In-Reply-To: Your message of "Tue, 26 Aug 2008 20:03:35 PDT." <48B4C407.9010900@miralink.com> Message-ID: <200808270540.FAA16991@sopwith.solgatos.com> > > What does penguinix call firewire? > > > > (none):~ # dmesg | grep -i fire > > (none):~ # dmesg | grep -i fw > > (none):~ # dmesg | grep -i 1394 > > (none):~ # dmesg | grep -i link > > audit: initializing netlink socket (disabled) > > eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] > > > > (none):~ # man -k fire > > fire: nothing appropriate. > > (none):~ # man -k fw > > fw: nothing appropriate. > > (none):~ # man -k 1394 > > 1394: nothing appropriate. > > (none):~ # man -k link > > link: nothing appropriate. > > > > > I was hoping that you could boot linux, and then plugin your camera and > see what the output of dmesg and /var/log/messages has to say. Shouldn't linux print something in dmesg about the controllers? Shouldn't there be man pages? But who cares? See below. > > Anyway, due to a firmware bug I ended up having to power cycle > > the machine. (switched off at the P/S, so even 5V standby should > > have been off) > > > > I was expecting the power cycle to completely reset the NEC board. > > But it is not back to normal. I no longer get the spewage from a > > constant series of bus resets, but fwcontrol -R still doesn't work. > > > > fwcontrol_prev is from March, and used to do -R successfully. > > > > fwcontrol_prev -R /dv0/test_prev_camera.dv > > Detected DV format on input. > > (EAGAIN) > > (EAGAIN) > > (EAGAIN) > > > > > Is there any chance that you overwrote fwcontrol_prev with my patched > version? No. The modification date is March 5th, which is when the very useful -f option was added. This version was used successfully used with -R before I tried the recent modifications. Today's mistake was forgetting to include the "-u 1", so it was looking for DV from the VIA controller. With -u 1 it is working fine. So the power cycle *did* fix it. Whew! So why does fwcontrol print "Detected DV format on input." when there isn't even a device plugged into the bus? Very misleading! From freebsd at sopwith.solgatos.com Thu Aug 28 23:14:35 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Thu Aug 28 23:14:41 2008 Subject: This is where I'm going with fwcontrol In-Reply-To: Your message of "Mon, 11 Aug 2008 18:07:03 PDT." <48A0E237.5020702@miralink.com> Message-ID: <200808282313.XAA17597@sopwith.solgatos.com> While looking at the code and wondering what "adjust_gap_count" had to do with cyclemaster mode, I noticed that -f was setting the 2nd argument to send_phy_config(int fd, int root_node, int gap_count) which is root_node, not gap_count. I also noticed that send_phy_config() does (root_node & 0x3f), so having the range check be 0x3f rather than INT32_MAX seems to make sense. I haven't yet figured out exactly which 7 bits this stuff is actually setting. So does the following look like an improvement (however minor) to anyone else, or just me? :-) @@ -730,7 +730,7 @@ bool dump_phy_reg = false; int32_t priority_budget = -1; - int32_t adjust_gap_count = -1; + int32_t set_root_node = -1; int32_t reset_gap_count = -1; int32_t send_link_on = -1; int32_t send_reset_start = -1; @@ -790,9 +790,9 @@ display_board_only = false; break; case 'f': - adjust_gap_count = strtol(optarg, NULL, 0); - if ( (adjust_gap_count < 0) || (adjust_gap_count > INT32_MAX) ) - err(EX_USAGE, "%s:adjust_gap_count out of range", __func__); + set_root_node = strtol(optarg, NULL, 0); + if ( (set_root_node < 0) || (set_root_node > 0x3f) ) + err(EX_USAGE, "%s:set_root_node out of range", __func__); open_needed = true; command_set = true; display_board_only = false; @@ -961,8 +961,8 @@ /* * Adjust the gap count for this card/bus to value "-f" */ - if (adjust_gap_count >= 0) - send_phy_config(fd, adjust_gap_count, -1); + if (set_root_node >= 0) + send_phy_config(fd, set_root_node, -1); /* * Reset the gap count for this card/bus "-g" From sbruno at miralink.com Thu Aug 28 23:49:06 2008 From: sbruno at miralink.com (Sean Bruno) Date: Thu Aug 28 23:49:15 2008 Subject: This is where I'm going with fwcontrol In-Reply-To: <200808282313.XAA17597@sopwith.solgatos.com> References: <200808282313.XAA17597@sopwith.solgatos.com> Message-ID: <48B73971.90706@miralink.com> Dieter wrote: > While looking at the code and wondering what "adjust_gap_count" > had to do with cyclemaster mode, I noticed that -f was setting > the 2nd argument to > send_phy_config(int fd, int root_node, int gap_count) > which is root_node, not gap_count. > > I also noticed that send_phy_config() does (root_node & 0x3f), > so having the range check be 0x3f rather than INT32_MAX > seems to make sense. > > Agreed, the root_node should be checked against 0x3f(or a define that is assigned the value of 0x3f ... whatever that really is). > I haven't yet figured out exactly which 7 bits this stuff is > actually setting. > > send_phy_config() is causing the /dev/fwX device to generate a PHY configuration Packet(IEEE 1394-1995 4.3.4.3) It is possible to optimize Serial Bus performance for particular configurations in the following ways: a) Setting the gap_count used by all nodes to a smaller value (appropriate to the actual worst-case number of hops between any two nodes) b) Forcing a particular node to be the root after the next bus initialization (for example, in isochronous systems, the root shall be cycle-master capable) Both of these actions shall be done for remote nodes using the PHY configuration packet shown in figure 4.20. (For the local node, the PH_CONT.request service is used) The procedures for using this PHY packet are described in clause 7.3.5.2.1. So, I think you are correct adjust_gap_count should become set_root_node as that is what it does. A PHY Config packet should look like this: Message ID Root ID R T Gap Count 00(2 bits) (5 bits) 1 1 (6 bits) So the Root ID(-f in fwcontrol) can't be set to a value greater than 0x3f(63) and the Gap Count can't be greater than 0x7f(127). An "R" value of 1 means that this is a message to set the root ID. An "T" value of 1 means that this is a message to set the gap count for all nodes. If "R" and "T" are both 0, then the message is ignored. > So does the following look like an improvement (however minor) > to anyone else, or just me? :-) > > > @@ -730,7 +730,7 @@ > bool dump_phy_reg = false; > > int32_t priority_budget = -1; > - int32_t adjust_gap_count = -1; > + int32_t set_root_node = -1; > int32_t reset_gap_count = -1; > int32_t send_link_on = -1; > int32_t send_reset_start = -1; > @@ -790,9 +790,9 @@ > display_board_only = false; > break; > case 'f': > - adjust_gap_count = strtol(optarg, NULL, 0); > - if ( (adjust_gap_count < 0) || (adjust_gap_count > INT32_MAX) ) > - err(EX_USAGE, "%s:adjust_gap_count out of range", __func__); > + set_root_node = strtol(optarg, NULL, 0); > + if ( (set_root_node < 0) || (set_root_node > 0x3f) ) > + err(EX_USAGE, "%s:set_root_node out of range", __func__); > open_needed = true; > command_set = true; > display_board_only = false; > @@ -961,8 +961,8 @@ > /* > * Adjust the gap count for this card/bus to value "-f" > */ > - if (adjust_gap_count >= 0) > - send_phy_config(fd, adjust_gap_count, -1); > + if (set_root_node >= 0) > + send_phy_config(fd, set_root_node, -1); > > /* > * Reset the gap count for this card/bus "-g" > I will chew on and implement this patch tomorrow I think. It makes sense to me, it's just the code in send_phy_config() that is distracting. I hope this clarifies what this crap means! :) -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com From freebsd at sopwith.solgatos.com Fri Aug 29 01:02:15 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Fri Aug 29 01:02:21 2008 Subject: This is where I'm going with fwcontrol In-Reply-To: Your message of "Thu, 28 Aug 2008 16:49:05 PDT." <48B73971.90706@miralink.com> Message-ID: <200808290101.BAA25511@sopwith.solgatos.com> > send_phy_config() is causing the /dev/fwX device to generate a PHY > configuration Packet(IEEE 1394-1995 4.3.4.3) > > It is possible to optimize Serial Bus performance for particular > configurations in the following ways: > a) Setting the gap_count used by all nodes to a smaller value > (appropriate to the actual worst-case number of > hops between any two nodes) > b) Forcing a particular node to be the root after the next bus > initialization (for example, in isochronous systems, > the root shall be cycle-master capable) > Both of these actions shall be done for remote nodes using the PHY > configuration packet shown in figure 4.20. (For the > local node, the PH_CONT.request service is used) The procedures for > using this PHY packet are described in clause > 7.3.5.2.1. > > > So, I think you are correct adjust_gap_count should become set_root_node > as that is what it does. > > A PHY Config packet should look like this: > Message ID Root ID R T Gap Count > 00(2 bits) (5 bits) 1 1 (6 bits) > > So the Root ID(-f in fwcontrol) can't be set to a value greater than > 0x3f(63) and the Gap Count can't be greater than 0x7f(127). An "R" > value of 1 means that this is a message to set the root ID. An "T" > value of 1 means that this is a message to set the gap count for all > nodes. If "R" and "T" are both 0, then the message is ignored. Thank you, this makes much more sense now! I was looking at controller registers, but it is building a packet. Suggestion: put something like the text above in a comment at the start of send_phy_config(). From freebsd at sopwith.solgatos.com Fri Aug 29 02:35:37 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Fri Aug 29 02:35:43 2008 Subject: This is where I'm going with fwcontrol In-Reply-To: Your message of "Thu, 28 Aug 2008 16:49:05 PDT." <48B73971.90706@miralink.com> Message-ID: <200808290234.CAA18841@sopwith.solgatos.com> More nit picking :-) Should > Message ID Root ID R T Gap Count > 00(2 bits) (5 bits) 1 1 (6 bits) be Message ID Root ID R T Gap Count 00(2 bits) (6 bits) 1 1 (6 bits) send_phy_config() ANDs root_node with 0x3f, and the "Physical ID" field in the controller register is 6 bits. From freebsd at sopwith.solgatos.com Fri Aug 29 16:28:33 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Fri Aug 29 16:28:40 2008 Subject: This is where I'm going with fwcontrol In-Reply-To: Your message of "Thu, 28 Aug 2008 16:49:05 PDT." <48B73971.90706@miralink.com> Message-ID: <200808291626.QAA13259@sopwith.solgatos.com> I looked at the changes NetBSD made to fwcontrol.c with the idea of tweaking FreeBSD's version so it would compile on both OSes. Below is a patch that might be enough. They made more changes than this. Some are clearly not essential (whitespace, putting the usage message into alphabetical order, ...), some I'm not sure about so I left them out for now. The full set of changes they did can be viewed by diffing FreeBSD cvs 1.23 with NetBSD cvs 1.7. It still compiles fine on FreeBSD 7.0 amd64, (and the getprogname() thing works) I haven't tried NetBSD yet. =================================================================== RCS file: RCS/fwcontrol.c,v retrieving revision 1.2.2.2 diff -u -r1.2.2.2 fwcontrol.c --- fwcontrol.c 2008/08/29 15:50:16 1.2.2.2 +++ fwcontrol.c 2008/08/29 16:00:48 @@ -32,8 +32,10 @@ * SUCH DAMAGE. */ +#if defined(__FreeBSD__) #include __FBSDID("$FreeBSD: src/usr.sbin/fwcontrol/fwcontrol.c,v 1.23.2.1 2008/05/02 06:15:58 simokawa Exp $"); +#endif #include #include @@ -42,11 +44,22 @@ #include #include #include +#if defined(__FreeBSD__) #include #include #include #include #include +#elif defined(__NetBSD__) +#include "eui64.h" +#include +#include +#include +#include +#else +#warning "You need to add support for your OS" +#endif + #include #include @@ -66,7 +79,7 @@ usage(void) { fprintf(stderr, - "fwcontrol [-u bus_num] [-prt] [-c node] [-d node] [-o node] [-s node]\n" + "%s [-u bus_num] [-prt] [-c node] [-d node] [-o node] [-s node]\n" "\t [-l file] [-g gap_count] [-f force_root ] [-b pri_req]\n" "\t [-M mode] [-R filename] [-S filename] [-m EUI64 | hostname]\n" "\t-u: specify bus number\n" @@ -84,7 +97,8 @@ "\t-M: specify dv or mpeg\n" "\t-R: Receive DV or MPEG TS stream\n" "\t-S: Send DV stream\n" - "\t-m: set fwmem target\n"); + "\t-m: set fwmem target\n" + , getprogname() ); exit(EX_USAGE); } @@ -981,8 +995,16 @@ if (set_fwmem_target) { eui.hi = ntohl(*(u_int32_t*)&(target.octet[0])); eui.lo = ntohl(*(u_int32_t*)&(target.octet[4])); +#if defined(__FreeBSD__) sysctl_set_int("hw.firewire.fwmem.eui64_hi", eui.hi); sysctl_set_int("hw.firewire.fwmem.eui64_lo", eui.lo); +#elif defined(__NetBSD__) + sysctl_set_int("hw.fwmem.eui64_hi", eui.hi); + sysctl_set_int("hw.fwmem.eui64_lo", eui.lo); +#else +#warning "You need to add support for your OS" +#endif + } /* From sbruno at miralink.com Fri Aug 29 17:55:36 2008 From: sbruno at miralink.com (Sean Bruno) Date: Fri Aug 29 17:55:43 2008 Subject: This is where I'm going with fwcontrol In-Reply-To: <200808291626.QAA13259@sopwith.solgatos.com> References: <200808291626.QAA13259@sopwith.solgatos.com> Message-ID: <48B83817.8050508@miralink.com> Dieter wrote: > I looked at the changes NetBSD made to fwcontrol.c > with the idea of tweaking FreeBSD's version so it would > compile on both OSes. Below is a patch that might be enough. > They made more changes than this. Some are clearly not essential > (whitespace, putting the usage message into alphabetical order, ...), > some I'm not sure about so I left them out for now. The full set > of changes they did can be viewed by diffing FreeBSD cvs 1.23 > with NetBSD cvs 1.7. It still compiles fine on FreeBSD 7.0 amd64, > (and the getprogname() thing works) I haven't tried NetBSD yet. > > =================================================================== > RCS file: RCS/fwcontrol.c,v > retrieving revision 1.2.2.2 > diff -u -r1.2.2.2 fwcontrol.c > --- fwcontrol.c 2008/08/29 15:50:16 1.2.2.2 > +++ fwcontrol.c 2008/08/29 16:00:48 > @@ -32,8 +32,10 @@ > * SUCH DAMAGE. > */ > > +#if defined(__FreeBSD__) > #include > __FBSDID("$FreeBSD: src/usr.sbin/fwcontrol/fwcontrol.c,v 1.23.2.1 2008/05/02 06:15:58 simokawa Exp $"); > +#endif > > #include > #include > @@ -42,11 +44,22 @@ > #include > #include > #include > +#if defined(__FreeBSD__) > #include > #include > #include > #include > #include > +#elif defined(__NetBSD__) > +#include "eui64.h" > +#include > +#include > +#include > +#include > +#else > +#warning "You need to add support for your OS" > +#endif > + > > #include > #include > @@ -66,7 +79,7 @@ > usage(void) > { > fprintf(stderr, > - "fwcontrol [-u bus_num] [-prt] [-c node] [-d node] [-o node] [-s node]\n" > + "%s [-u bus_num] [-prt] [-c node] [-d node] [-o node] [-s node]\n" > "\t [-l file] [-g gap_count] [-f force_root ] [-b pri_req]\n" > "\t [-M mode] [-R filename] [-S filename] [-m EUI64 | hostname]\n" > "\t-u: specify bus number\n" > @@ -84,7 +97,8 @@ > "\t-M: specify dv or mpeg\n" > "\t-R: Receive DV or MPEG TS stream\n" > "\t-S: Send DV stream\n" > - "\t-m: set fwmem target\n"); > + "\t-m: set fwmem target\n" > + , getprogname() ); > exit(EX_USAGE); > } > > @@ -981,8 +995,16 @@ > if (set_fwmem_target) { > eui.hi = ntohl(*(u_int32_t*)&(target.octet[0])); > eui.lo = ntohl(*(u_int32_t*)&(target.octet[4])); > +#if defined(__FreeBSD__) > sysctl_set_int("hw.firewire.fwmem.eui64_hi", eui.hi); > sysctl_set_int("hw.firewire.fwmem.eui64_lo", eui.lo); > +#elif defined(__NetBSD__) > + sysctl_set_int("hw.fwmem.eui64_hi", eui.hi); > + sysctl_set_int("hw.fwmem.eui64_lo", eui.lo); > +#else > +#warning "You need to add support for your OS" > +#endif > + > } > > /* > Since my current patch-set is fairly extensive in it's current state, I'm going to defer application of this patch for a while. -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com From sbruno at miralink.com Fri Aug 29 18:16:29 2008 From: sbruno at miralink.com (Sean Bruno) Date: Fri Aug 29 18:16:35 2008 Subject: This is where I'm going with fwcontrol In-Reply-To: <200808290234.CAA18841@sopwith.solgatos.com> References: <200808290234.CAA18841@sopwith.solgatos.com> Message-ID: <48B83CFC.6030906@miralink.com> Dieter wrote: > More nit picking :-) > > Should > > >> Message ID Root ID R T Gap Count >> 00(2 bits) (5 bits) 1 1 (6 bits) >> > > be > > Message ID Root ID R T Gap Count > 00(2 bits) (6 bits) 1 1 (6 bits) > > send_phy_config() ANDs root_node with 0x3f, and the > "Physical ID" field in the controller register is > 6 bits. > Well, according to the 1394 documentation, no. The root ID is definitely 5 bits. The gap count is also 5 bits, I must have mis-counted. So, really it should be: Message ID Root ID R T Gap Count 00(2 bits) (5 bits) 1 1 (5 bits) This means that the Root ID and the Gap Count cannot exceed 0x3f(63). So, the masking of the values instead of generating and error seems wrong to me. I'm going to put in error checking to make sure the values comply with the specification and document the correct values in the man page and the comments of the code. -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com From freebsd at sopwith.solgatos.com Fri Aug 29 20:22:42 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Fri Aug 29 20:22:48 2008 Subject: This is where I'm going with fwcontrol In-Reply-To: Your message of "Fri, 29 Aug 2008 11:16:28 PDT." <48B83CFC.6030906@miralink.com> Message-ID: <200808292021.UAA25442@sopwith.solgatos.com> > > Should > > > > > >> Message ID Root ID R T Gap Count > >> 00(2 bits) (5 bits) 1 1 (6 bits) > >> > > > > be > > > > Message ID Root ID R T Gap Count > > 00(2 bits) (6 bits) 1 1 (6 bits) > > > > send_phy_config() ANDs root_node with 0x3f, and the > > "Physical ID" field in the controller register is > > 6 bits. > > > Well, according to the 1394 documentation, no. The root ID is > definitely 5 bits. > > The gap count is also 5 bits, I must have mis-counted. So, really it > should be: > > Message ID Root ID R T Gap Count > 00(2 bits) (5 bits) 1 1 (5 bits) Looking at "Table 5. PHY Register Map" in the VIA controller datasheet (page 24 of the pdf) http://www.datasheetarchive.com/pdf-datasheets/Datasheets-6/DSA-113181.pdf the "Physical ID" field is 6 bits, as is the "Gap Count" field. I don't have the IEEE documentation, so I'll have to assume you are correct about it saying 5 bits. So why doesn't the controller datasheet agree with the IEEE doc? Granted one is a controller register and the other is a packet, but I'd expect these individual fields to be the same size. > This means that the Root ID and the Gap Count cannot exceed 0x3f(63). That's 6 bits. 5 bits would be 0x1f = 31 decimal. > So, the masking > of the values instead of generating and error seems wrong to me. I'm > going to put in error checking > to make sure the values comply with the specification and document the > correct values in the man page > and the comments of the code. Sounds good. From sbruno at miralink.com Fri Aug 29 21:02:52 2008 From: sbruno at miralink.com (Sean Bruno) Date: Fri Aug 29 21:02:58 2008 Subject: This is where I'm going with fwcontrol In-Reply-To: <200808292021.UAA25442@sopwith.solgatos.com> References: <200808292021.UAA25442@sopwith.solgatos.com> Message-ID: <48B863FB.10202@miralink.com> Dieter wrote: >>> Should >>> >>> >>> >>>> Message ID Root ID R T Gap Count >>>> 00(2 bits) (5 bits) 1 1 (6 bits) >>>> >>>> >>> >>> be >>> >>> Message ID Root ID R T Gap Count >>> 00(2 bits) (6 bits) 1 1 (6 bits) >>> >>> send_phy_config() ANDs root_node with 0x3f, and the >>> "Physical ID" field in the controller register is >>> 6 bits. >>> >>> >> Well, according to the 1394 documentation, no. The root ID is >> definitely 5 bits. >> >> The gap count is also 5 bits, I must have mis-counted. So, really it >> should be: >> >> Message ID Root ID R T Gap Count >> 00(2 bits) (5 bits) 1 1 (5 bits) >> > > Looking at "Table 5. PHY Register Map" in the VIA controller datasheet > (page 24 of the pdf) > http://www.datasheetarchive.com/pdf-datasheets/Datasheets-6/DSA-113181.pdf > > the "Physical ID" field is 6 bits, as is the "Gap Count" field. > I don't have the IEEE documentation, so I'll have to assume > you are correct about it saying 5 bits. So why doesn't the > controller datasheet agree with the IEEE doc? Granted one is > a controller register and the other is a packet, but I'd > expect these individual fields to be the same size. > > >> This means that the Root ID and the Gap Count cannot exceed 0x3f(63). >> > > That's 6 bits. 5 bits would be 0x1f = 31 decimal. > > Huh....I seem to be having some kind of wierd PDF rendering issue. Ok, so looking at the document in another application(not acroread), the Node ID is 6 bits, the Gap Count is 6 bits. I'm the crazy one I guess. Wierd. >> So, the masking >> of the values instead of generating and error seems wrong to me. I'm >> going to put in error checking >> to make sure the values comply with the specification and document the >> correct values in the man page >> and the comments of the code. >> > > Sounds good. > -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com From sbruno at miralink.com Fri Aug 29 21:18:13 2008 From: sbruno at miralink.com (Sean Bruno) Date: Fri Aug 29 21:18:32 2008 Subject: New and improved? patch Message-ID: <48B86793.6080404@miralink.com> Freshly updated with new found information on what the heck -f -g actually do! See how this behaves for you. -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com -------------- next part -------------- Index: fwcontrol.8 =================================================================== --- fwcontrol.8 (revision 182455) +++ fwcontrol.8 (working copy) @@ -59,7 +59,7 @@ The following options are available: .Bl -tag -width indent .It Fl u Ar bus_num -Specify the FireWire bus number to be operated on. +Specify the FireWire bus number to be operated on. Default is bus 0. .It Fl r Initiate bus reset. .It Fl t @@ -81,11 +81,14 @@ .It Fl f Ar node Force specified .Ar node -to be the root node on the next bus reset. +to be the root node on the next bus reset by sending a PHY config packet. +Valid values are 0 - 63. .It Fl g Ar gap_count -Broadcast +Broadcast new .Ar gap_count -by phy_config packet. +by sending a PHY_config packet. +By default this value is 63 on all nodes. +Valid values are 0 - 63. .It Fl i Ar pri_req Set the .Dv PRIORITY_BUDGET Index: fwcontrol.c =================================================================== --- fwcontrol.c (revision 182455) +++ fwcontrol.c (working copy) @@ -56,6 +56,8 @@ #include #include #include +#include +#include #include "fwmethods.h" static void sysctl_set_int(const char *, int); @@ -64,21 +66,22 @@ usage(void) { fprintf(stderr, - "fwcontrol [-u bus_num] [-rt] [-f node] [-g gap_count] " - "[-o node] " - "[-b pri_req] [-c node] [-d node] [-l file] " - "[-R file] [-S file] [-m target]\n" + "fwcontrol [-u bus_num] [-prt] [-c node] [-d node] [-o node] [-s node]\n" + "\t [-l file] [-g gap_count] [-f force_root ] [-b pri_req]\n" + "\t [-M mode] [-R filename] [-S filename] [-m EUI64 | hostname]\n" "\t-u: specify bus number\n" - "\t-f: broadcast force_root by phy_config packet\n" - "\t-g: broadcast gap_count by phy_config packet\n" - "\t-o: send link-on packet to the node\n" - "\t-s: write RESET_START register on the node\n" - "\t-b: set PRIORITY_BUDGET register on all supported nodes\n" - "\t-c: read configuration ROM\n" + "\t-p: Display current PHY register settings\n" "\t-r: bus reset\n" "\t-t: read topology map\n" + "\t-c: read configuration ROM\n" "\t-d: hex dump of configuration ROM\n" + "\t-o: send link-on packet to the node\n" + "\t-s: write RESET_START register on the node\n" "\t-l: load and parse hex dump file of configuration ROM\n" + "\t-g: broadcast gap_count by phy_config packet\n" + "\t-f: broadcast force_root by phy_config packet\n" + "\t-b: set PRIORITY_BUDGET register on all supported nodes\n" + "\t-M: specify dv or mpeg\n" "\t-R: Receive DV or MPEG TS stream\n" "\t-S: Send DV stream\n" "\t-m: set fwmem target\n"); @@ -92,18 +95,14 @@ *(u_int32_t*)&(eui->octet[4]) = htonl(fweui->lo); } -static struct fw_devlstreq * -get_dev(int fd) +static void +get_dev(int fd, struct fw_devlstreq *data) { - struct fw_devlstreq *data; - - data = (struct fw_devlstreq *)malloc(sizeof(struct fw_devlstreq)); if (data == NULL) - err(1, "malloc"); + err(EX_SOFTWARE, "%s: data malloc", __func__); if( ioctl(fd, FW_GDEVLST, data) < 0) { - err(1, "ioctl"); + err(EX_IOERR, "%s: ioctl", __func__); } - return data; } static int @@ -130,17 +129,25 @@ if (eui64_hostton(nodestr, &eui) != 0 && eui64_aton(nodestr, &eui) != 0) return (-1); - data = get_dev(fd); + data = (struct fw_devlstreq *)malloc(sizeof(struct fw_devlstreq)); + if (data == NULL) + err(EX_SOFTWARE, "%s: data malloc", __func__); + get_dev(fd,data); for (i = 0; i < data->info_len; i++) { fweui2eui64(&data->dev[i].eui, &tmpeui); if (memcmp(&eui, &tmpeui, sizeof(struct eui64)) == 0) { node = data->dev[i].dst; + if (data != NULL) + free(data); goto gotnode; } } - if (i >= data->info_len) + if (i >= data->info_len) { + if (data != NULL) + free(data); return (-1); + } gotnode: if (node < 0 || node > 63) @@ -158,7 +165,10 @@ char addr[EUI64_SIZ], hostname[40]; int i; - data = get_dev(fd); + data = (struct fw_devlstreq *)malloc(sizeof(struct fw_devlstreq)); + if (data == NULL) + err(EX_SOFTWARE, "%s:data malloc", __func__); + get_dev(fd, data); printf("%d devices (info_len=%d)\n", data->n, data->info_len); printf("node EUI64 status hostname\n"); for (i = 0; i < data->info_len; i++) { @@ -184,6 +194,8 @@ u_int32_t *qld, res; asyreq = (struct fw_asyreq *)malloc(sizeof(struct fw_asyreq_t) + 16); + if (asyreq == NULL) + err(EX_SOFTWARE, "%s:asyreq malloc", __func__); asyreq->req.len = 16; #if 0 asyreq->req.type = FWASREQNODE; @@ -206,7 +218,7 @@ asyreq->pkt.mode.wreqq.data = htonl(data); if (ioctl(fd, FW_ASYREQ, asyreq) < 0) { - err(1, "ioctl"); + err(EX_IOERR, "%s: ioctl", __func__); } res = qld[3]; free(asyreq); @@ -216,37 +228,56 @@ return 0; } +/* + * Send a PHY Config Packet + * ieee 1394a-2005 4.3.4.3 + * + * Message ID Root ID R T Gap Count + * 00(2 bits) (6 bits) 1 1 (6 bits) + * + * if "R" is set, then Root ID will be the next + * root node upon the next bus reset. + * if "T" is set, then Gap Count will be the + * value that all nodes use for their Gap Count + * if "R" and "T" are not set, then this message + * is either ignored or interpreted as an extended + * PHY config Packet as per 1394a-2005 4.3.4.4 + */ static void send_phy_config(int fd, int root_node, int gap_count) { struct fw_asyreq *asyreq; asyreq = (struct fw_asyreq *)malloc(sizeof(struct fw_asyreq_t) + 12); + if (asyreq == NULL) + err(EX_SOFTWARE, "%s:asyreq malloc", __func__); asyreq->req.len = 12; asyreq->req.type = FWASREQNODE; asyreq->pkt.mode.ld[0] = 0; asyreq->pkt.mode.ld[1] = 0; asyreq->pkt.mode.common.tcode = FWTCODE_PHY; if (root_node >= 0) - asyreq->pkt.mode.ld[1] |= (root_node & 0x3f) << 24 | 1 << 23; + asyreq->pkt.mode.ld[1] |= ((root_node << 24) | (1 << 23)); if (gap_count >= 0) - asyreq->pkt.mode.ld[1] |= 1 << 22 | (gap_count & 0x3f) << 16; + asyreq->pkt.mode.ld[1] |= ((1 << 22) | (gap_count << 16)); asyreq->pkt.mode.ld[2] = ~asyreq->pkt.mode.ld[1]; printf("send phy_config root_node=%d gap_count=%d\n", root_node, gap_count); if (ioctl(fd, FW_ASYREQ, asyreq) < 0) - err(1, "ioctl"); + err(EX_IOERR, "%s: ioctl", __func__); free(asyreq); } static void -send_link_on(int fd, int node) +link_on(int fd, int node) { struct fw_asyreq *asyreq; asyreq = (struct fw_asyreq *)malloc(sizeof(struct fw_asyreq_t) + 12); + if (asyreq == NULL) + err(EX_SOFTWARE, "%s:asyreq malloc", __func__); asyreq->req.len = 12; asyreq->req.type = FWASREQNODE; asyreq->pkt.mode.common.tcode = FWTCODE_PHY; @@ -254,7 +285,7 @@ asyreq->pkt.mode.ld[2] = ~asyreq->pkt.mode.ld[1]; if (ioctl(fd, FW_ASYREQ, asyreq) < 0) - err(1, "ioctl"); + err(EX_IOERR, "%s: ioctl", __func__); free(asyreq); } @@ -264,6 +295,8 @@ struct fw_asyreq *asyreq; asyreq = (struct fw_asyreq *)malloc(sizeof(struct fw_asyreq_t) + 16); + if (asyreq == NULL) + err(EX_SOFTWARE, "%s:asyreq malloc", __func__); asyreq->req.len = 16; asyreq->req.type = FWASREQNODE; asyreq->pkt.mode.wreqq.dst = FWLOCALBUS | (node & 0x3f); @@ -276,7 +309,7 @@ asyreq->pkt.mode.wreqq.data = htonl(0x1); if (ioctl(fd, FW_ASYREQ, asyreq) < 0) - err(1, "ioctl"); + err(EX_IOERR, "%s: ioctl", __func__); free(asyreq); } @@ -290,7 +323,10 @@ u_int32_t max, reg, old; int i; - data = get_dev(fd); + data = (struct fw_devlstreq *)malloc(sizeof(struct fw_devlstreq)); + if (data == NULL) + err(EX_SOFTWARE, "%s:data malloc", __func__); + get_dev(fd, data); #define BUGET_REG 0xf0000218 for (i = 0; i < data->info_len; i++) { devinfo = &data->dev[i]; @@ -344,7 +380,10 @@ int i, error; struct fw_devlstreq *data; - data = get_dev(fd); + data = (struct fw_devlstreq *)malloc(sizeof(struct fw_devlstreq)); + if (data == NULL) + err(EX_SOFTWARE, "%s:data malloc", __func__); + get_dev(fd, data); for (i = 0; i < data->info_len; i++) { if (data->dev[i].dst == node && data->dev[i].eui.lo != 0) @@ -360,7 +399,7 @@ buf.ptr = crom_buf; bzero(crom_buf, len); if ((error = ioctl(fd, FW_GCROM, &buf)) < 0) { - err(1, "ioctl"); + err(EX_IOERR, "%s: ioctl", __func__); } return error; @@ -469,9 +508,9 @@ static const char *speed[] = {"S100", "S200", "S400", "S800"}; tmap = malloc(sizeof(struct fw_topology_map)); if (tmap == NULL) - return; + err(EX_SOFTWARE, "%s:tmap malloc", __func__); if (ioctl(fd, FW_GTPMAP, tmap) < 0) { - err(1, "ioctl"); + err(EX_IOERR, "%s: ioctl", __func__); } printf("crc_len: %d generation:%d node_count:%d sid_count:%d\n", tmap->crc_len, tmap->generation, @@ -512,7 +551,7 @@ for (i = 0; i < len; i++) { reg.addr = offset + i; if (ioctl(fd, FWOHCI_RDPHYREG, ®) < 0) - err(1, "ioctl"); + err(EX_IOERR, "%s: ioctl", __func__); buf[i] = (u_int8_t) reg.data; printf("0x%02x ", reg.data); } @@ -527,7 +566,7 @@ reg.addr = 0x7; reg.data = ((page & 7) << 5) | (port & 0xf); if (ioctl(fd, FWOHCI_WRPHYREG, ®) < 0) - err(1, "ioctl"); + err(EX_IOERR, "%s: ioctl", __func__); read_phy_registers(fd, buf, 8, 8); } @@ -590,22 +629,16 @@ ); } -static void -open_dev(int *fd, char *devbase) +static int +open_dev(int *fd, char *devname) { - char name[256]; - int i; - if (*fd < 0) { - for (i = 0; i < 4; i++) { - snprintf(name, sizeof(name), "%s.%d", devbase, i); - if ((*fd = open(name, O_RDWR)) >= 0) - break; - } + *fd = open(devname, O_RDWR); if (*fd < 0) - err(1, "open"); + return(-1); } + return(0); } static void @@ -625,25 +658,40 @@ u_int32_t *ptr; struct ciphdr *ciph; fwmethod *retfn; +#define RECV_NUM_PACKET 16 +#define RECV_PACKET_SZ 1024 bufreq.rx.nchunk = 8; - bufreq.rx.npacket = 16; - bufreq.rx.psize = 1024; + bufreq.rx.npacket = RECV_NUM_PACKET; + bufreq.rx.psize = RECV_PACKET_SZ; bufreq.tx.nchunk = 0; bufreq.tx.npacket = 0; bufreq.tx.psize = 0; if (ioctl(fd, FW_SSTBUF, &bufreq) < 0) - err(1, "ioctl FW_SSTBUF"); + err(EX_IOERR, "%s: ioctl FW_SSTBUF", __func__); isoreq.ch = ich & 0x3f; isoreq.tag = (ich >> 6) & 3; if (ioctl(fd, FW_SRSTREAM, &isoreq) < 0) - err(1, "ioctl FW_SRSTREAM"); + err(EX_IOERR, "%s: ioctl FW_SRSTREAM", __func__); - buf = (char *)malloc(1024*16); - len = read(fd, buf, 1024*16); + buf = (char *)malloc(RECV_NUM_PACKET * RECV_PACKET_SZ); + if (buf == NULL) + err(EX_SOFTWARE, "%s:buf malloc", __func__); + /* + * fwdev.c seems to return EIO on error and + * the return value of the last uiomove + * on success. For now, checking that the + * return is not less than zero should be + * sufficient. fwdev.c::fw_read() should + * return the total length read, not the value + * of the last uiomove(). + */ + len = read(fd, buf, RECV_NUM_PACKET * RECV_PACKET_SZ); + if (len < 0) + err(EX_IOERR, "%s: error reading from device\n", __func__); ptr = (u_int32_t *) buf; ciph = (struct ciphdr *)(ptr + 1); @@ -666,102 +714,168 @@ int main(int argc, char **argv) { +#define MAX_BOARDS 10 u_int32_t crom_buf[1024/4]; - char devbase[1024] = "/dev/fw0"; - int fd, ch, len=1024; + u_int32_t crom_buf_hex[1024/4]; + char devbase[64]; + const char *device_string = "/dev/fw"; + int fd = -1, ch, len=1024; + int32_t current_board = 0; + /* + * If !command_set, then -u will display the nodes for the board. + * This emulates the previous behavior when -u is passed by itself + */ + bool command_set = false; + bool open_needed = false; long tmp; struct fw_eui64 eui; struct eui64 target; fwmethod *recvfn = NULL; +/* + * Holders for which functions + * to iterate through + */ + bool display_board_only = false; + bool display_crom = false; + bool send_bus_reset = false; + bool display_crom_hex = false; + bool load_crom_from_file = false; + bool set_fwmem_target = false; + bool dump_topology = false; + bool dump_phy_reg = false; - fd = -1; + int32_t priority_budget = -1; + int32_t set_root_node = -1; + int32_t set_gap_count = -1; + int32_t send_link_on = -1; + int32_t send_reset_start = -1; + char *crom_string = NULL; + char *crom_string_hex = NULL; + char *recv_data = NULL; + char *send_data = NULL; + if (argc < 2) { - open_dev(&fd, devbase); - list_dev(fd); + for (current_board = 0; current_board < MAX_BOARDS; current_board++) { + snprintf(devbase, sizeof(devbase), "%s%d", device_string, current_board); + if (open_dev(&fd, devbase) < 0) { + if (current_board == 0) { + usage(); + } + return(EIO); + } + list_dev(fd); + close(fd); + fd = -1; + } } - - while ((ch = getopt(argc, argv, "M:f:g:m:o:s:b:prtc:d:l:u:R:S:")) != -1) + /* + * Parse all command line options, then execute requested operations. + */ + while ((ch = getopt(argc, argv, "M:f:g:m:o:s:b:prtc:d:l:u:R:S:")) != -1) { switch(ch) { case 'b': - tmp = strtol(optarg, NULL, 0); - if (tmp < 0 || tmp > (long)0xffffffff) - errx(EX_USAGE, "invalid number: %s", optarg); - open_dev(&fd, devbase); - set_pri_req(fd, tmp); + priority_budget = strtol(optarg, NULL, 0); + if (priority_budget < 0 || priority_budget > INT32_MAX) + errx(EX_USAGE, "%s: invalid number: %s", __func__, optarg); + command_set = true; + open_needed = true; + display_board_only = false; break; case 'c': - open_dev(&fd, devbase); - tmp = str2node(fd, optarg); - get_crom(fd, tmp, crom_buf, len); - show_crom(crom_buf); + crom_string = malloc(strlen(optarg)+1); + if (crom_string == NULL) + err(EX_SOFTWARE, "%s:crom_string malloc", __func__); + if ( (strtol(crom_string, NULL, 0) < 0) || strtol(crom_string, NULL, 0) > MAX_BOARDS) + err(EX_USAGE, "%s:Invalid value for node", __func__); + strcpy(crom_string, optarg); + display_crom = 1; + open_needed = true; + command_set = true; + display_board_only = false; break; case 'd': - open_dev(&fd, devbase); - tmp = str2node(fd, optarg); - get_crom(fd, tmp, crom_buf, len); - dump_crom(crom_buf); + crom_string_hex = malloc(strlen(optarg)+1); + if (crom_string_hex == NULL) + err(EX_SOFTWARE, "%s:crom_string_hex malloc", __func__); + strcpy(crom_string_hex, optarg); + display_crom_hex = 1; + open_needed = true; + command_set = true; + display_board_only = false; break; case 'f': - tmp = strtol(optarg, NULL, 0); - open_dev(&fd, devbase); - send_phy_config(fd, tmp, -1); +#define MAX_PHY_CONFIG 0x3f + set_root_node = strtol(optarg, NULL, 0); + if ( (set_root_node < 0) || (set_root_node > MAX_PHY_CONFIG) ) + err(EX_USAGE, "%s:set_root_node out of range", __func__); + open_needed = true; + command_set = true; + display_board_only = false; break; case 'g': - tmp = strtol(optarg, NULL, 0); - open_dev(&fd, devbase); - send_phy_config(fd, -1, tmp); + set_gap_count = strtol(optarg, NULL, 0); + if ( (set_gap_count < 0) || (set_gap_count > MAX_PHY_CONFIG) ) + err(EX_USAGE, "%s:set_gap_count out of range", __func__); + open_needed = true; + command_set = true; + display_board_only = false; break; case 'l': + load_crom_from_file = 1; load_crom(optarg, crom_buf); - show_crom(crom_buf); + command_set = true; + display_board_only = false; break; case 'm': - if (eui64_hostton(optarg, &target) != 0 && - eui64_aton(optarg, &target) != 0) - errx(EX_USAGE, "invalid target: %s", optarg); - eui.hi = ntohl(*(u_int32_t*)&(target.octet[0])); - eui.lo = ntohl(*(u_int32_t*)&(target.octet[4])); - sysctl_set_int("hw.firewire.fwmem.eui64_hi", eui.hi); - sysctl_set_int("hw.firewire.fwmem.eui64_lo", eui.lo); + set_fwmem_target = 1; + open_needed = 0; + command_set = true; + display_board_only = false; + if (eui64_hostton(optarg, &target) != 0 && + eui64_aton(optarg, &target) != 0) + err(EX_USAGE, "%s: invalid target: %s", __func__, optarg); break; case 'o': - open_dev(&fd, devbase); - tmp = str2node(fd, optarg); - send_link_on(fd, tmp); + send_link_on = str2node(fd, optarg); + if ( (send_link_on < 0) || (send_link_on > INT32_MAX) ) + err(EX_USAGE, "%s: node out of range: %s\n",__func__, optarg); + open_needed = true; + command_set = true; + display_board_only = false; break; case 'p': - open_dev(&fd, devbase); - dump_phy_registers(fd); + dump_phy_reg = 1; + open_needed = true; + command_set = true; + display_board_only = false; break; case 'r': - open_dev(&fd, devbase); - if(ioctl(fd, FW_IBUSRST, &tmp) < 0) - err(1, "ioctl"); + send_bus_reset = 1; + open_needed = true; + command_set = true; + display_board_only = false; break; case 's': - open_dev(&fd, devbase); - tmp = str2node(fd, optarg); - reset_start(fd, tmp); + send_reset_start = str2node(fd, optarg); + if ( (send_reset_start < 0) || (send_reset_start > INT32_MAX) ) + err(EX_USAGE, "%s: node out of range: %s\n", __func__, optarg); + open_needed = true; + command_set = true; + display_board_only = false; break; case 't': - open_dev(&fd, devbase); - show_topology_map(fd); + dump_topology = 1; + open_needed = true; + command_set = true; + display_board_only = false; break; case 'u': - tmp = strtol(optarg, NULL, 0); - snprintf(devbase, sizeof(devbase), "/dev/fw%ld", tmp); - if (fd > 0) { - close(fd); - fd = -1; - } - if (argc == optind) { - open_dev(&fd, devbase); - list_dev(fd); - } + if(!command_set) + display_board_only = true; + current_board = strtol(optarg, NULL, 0); + open_needed = true; break; -#define TAG (1<<6) -#define CHANNEL 63 case 'M': switch (optarg[0]) { case 'm': @@ -774,22 +888,164 @@ errx(EX_USAGE, "unrecognized method: %s", optarg); } + command_set = true; + display_board_only = false; break; case 'R': - open_dev(&fd, devbase); - if (recvfn == NULL) /* guess... */ - recvfn = detect_recv_fn(fd, TAG | CHANNEL); - close(fd); - fd = -1; - open_dev(&fd, devbase); - (*recvfn)(fd, optarg, TAG | CHANNEL, -1); + recv_data = malloc(strlen(optarg)+1); + if (recv_data == NULL) + err(EX_SOFTWARE, "%s:recv_data malloc", __func__); + strcpy(recv_data, optarg); + open_needed = false; + command_set = true; + display_board_only = false; break; case 'S': - open_dev(&fd, devbase); - dvsend(fd, optarg, TAG | CHANNEL, -1); + send_data = malloc(strlen(optarg)+1); + if (send_data == NULL) + err(EX_SOFTWARE, "%s:send_data malloc", __func__); + strcpy(send_data, optarg); + open_needed = true; + command_set = true; + display_board_only = false; break; default: usage(); + return 0; } + } /* end while */ + + /* + * If -u is passed, execute + * command for that card only. + * + * If -u is not passed, execute + * command for card 0 only. + * + */ + if(open_needed){ + snprintf(devbase, sizeof(devbase), "%s%d", device_string, current_board); + if (open_dev(&fd, devbase) < 0) { + errx(EX_IOERR, "%s: Error opening board #%d\n", __func__, current_board); + } + } + /* + * display the nodes on this board "-u" + * only + */ + if (display_board_only) + list_dev(fd); + + /* + * dump_phy_reg "-p" + */ + if (dump_phy_reg) + dump_phy_registers(fd); + + /* + * send a BUS_RESET Event "-r" + */ + if (send_bus_reset) { + if(ioctl(fd, FW_IBUSRST, &tmp) < 0) + err(EX_IOERR, "%s: ioctl", __func__); + } + /* + * Print out the CROM for this node "-c" + */ + if (display_crom) { + tmp = str2node(fd, crom_string); + get_crom(fd, tmp, crom_buf, len); + show_crom(crom_buf); + free(crom_string); + } + /* + * Hex Dump the CROM for this node "-d" + */ + if (display_crom_hex) { + tmp = str2node(fd, crom_string_hex); + get_crom(fd, tmp, crom_buf_hex, len); + dump_crom(crom_buf_hex); + free(crom_string_hex); + } + /* + * Set Priority Budget to value for this node "-b" + */ + if (priority_budget >= 0) + set_pri_req(fd, priority_budget); + + /* + * Explicitly set the root node of this bus to value "-f" + */ + if (set_root_node >= 0) + send_phy_config(fd, set_root_node, -1); + + /* + * Set the gap count for this card/bus "-g" + */ + if (set_gap_count >= 0) + send_phy_config(fd, -1, set_gap_count); + + /* + * Load a CROM from a file "-l" + */ + if (load_crom_from_file) + show_crom(crom_buf); + /* + * Set the fwmem target for a node to argument "-m" + */ + if (set_fwmem_target) { + eui.hi = ntohl(*(u_int32_t*)&(target.octet[0])); + eui.lo = ntohl(*(u_int32_t*)&(target.octet[4])); + sysctl_set_int("hw.firewire.fwmem.eui64_hi", eui.hi); + sysctl_set_int("hw.firewire.fwmem.eui64_lo", eui.lo); + } + + /* + * Send a link on to this board/bus "-o" + */ + if (send_link_on >= 0) + link_on(fd, send_link_on); + + /* + * Send a reset start to this board/bus "-s" + */ + if (send_reset_start >= 0) + reset_start(fd, send_reset_start); + + /* + * Dump the node topology for this board/bus "-t" + */ + if (dump_topology) + show_topology_map(fd); + + /* + * Recieve data file from node "-R" + */ +#define TAG (1<<6) +#define CHANNEL 63 + if (recv_data != NULL){ + if (recvfn == NULL) { /* guess... */ + recvfn = detect_recv_fn(fd, TAG | CHANNEL); + close(fd); + } + snprintf(devbase, sizeof(devbase), "%s%d", device_string, current_board); + if (open_dev(&fd, devbase) < 0) + errx(EX_IOERR, "%s: Error opening board #%d in recv_data\n", __func__, current_board); + (*recvfn)(fd, recv_data, TAG | CHANNEL, -1); + free(recv_data); + } + + /* + * Send data file to node "-S" + */ + if (send_data != NULL){ + dvsend(fd, send_data, TAG | CHANNEL, -1); + free(send_data); + } + + if (fd > 0) { + close(fd); + fd = -1; + } return 0; } From sbruno at miralink.com Fri Aug 29 21:42:54 2008 From: sbruno at miralink.com (Sean Bruno) Date: Fri Aug 29 21:43:19 2008 Subject: DEBUG flag in fwdv.c Message-ID: <48B86D5D.8060908@miralink.com> Oooooo...there's a "DEBUG" compile flag in fwdv.c ... care to set it to "1" and send me the output? It might clue me into what bit needs to be toggled to get your card back into shape. -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com From freebsd at sopwith.solgatos.com Fri Aug 29 23:32:35 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Fri Aug 29 23:32:45 2008 Subject: DEBUG flag in fwdv.c In-Reply-To: Your message of "Fri, 29 Aug 2008 14:42:53 PDT." <48B86D5D.8060908@miralink.com> Message-ID: <200808292331.XAA01489@sopwith.solgatos.com> > Oooooo...there's a "DEBUG" compile flag in fwdv.c ... care to set it to > "1" and send me the output? It might clue me into what bit needs to be > toggled to get your card back into shape. Which problem is this for? http://www.freebsd.org/cgi/query-pr.cgi?pr=113785 http://www.freebsd.org/cgi/query-pr.cgi?pr=118093 I thought the idea for PR 113785 was to get the controller into non-CYCLEMASTER mode? I can't figure out why fwcontrol -f works for NCR but not for VIA? I don't see what fwdv.c has to do with PR 118093. If you mean the NCR controller generating hundreds of bus resets, the power cycle fixed it. From sbruno at miralink.com Fri Aug 29 23:33:48 2008 From: sbruno at miralink.com (Sean Bruno) Date: Fri Aug 29 23:33:54 2008 Subject: DEBUG flag in fwdv.c In-Reply-To: <200808292331.XAA01489@sopwith.solgatos.com> References: <200808292331.XAA01489@sopwith.solgatos.com> Message-ID: <48B8875B.1010801@miralink.com> Dieter wrote: >> Oooooo...there's a "DEBUG" compile flag in fwdv.c ... care to set it to >> "1" and send me the output? It might clue me into what bit needs to be >> toggled to get your card back into shape. >> > > Which problem is this for? > > http://www.freebsd.org/cgi/query-pr.cgi?pr=113785 > http://www.freebsd.org/cgi/query-pr.cgi?pr=118093 > > I thought the idea for PR 113785 was to get the controller into > non-CYCLEMASTER mode? I can't figure out why fwcontrol -f works > for NCR but not for VIA? > > I don't see what fwdv.c has to do with PR 118093. > > If you mean the NCR controller generating hundreds of bus resets, > the power cycle fixed it. > Ah, so with the original fwcontrol you can still do everything that you used to do? I was under the impression that I had permanently destroyed something! :) -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com From freebsd at sopwith.solgatos.com Sun Aug 31 19:37:14 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Sun Aug 31 19:37:20 2008 Subject: New and improved? patch In-Reply-To: Your message of "Fri, 29 Aug 2008 14:18:11 PDT." <48B86793.6080404@miralink.com> Message-ID: <200808311934.TAA10392@sopwith.solgatos.com> >> Freshly updated with new found information on what the heck -f -g >> actually do! >> >> See how this behaves for you. usage: > [-f force_root ] Suggestion: [-f force_root_node ] or maybe "desired_root_node" or maybe "root_node" or maybe just "node", same as -c -d -o -s > -g: broadcast gap_count by phy_config packet Suggestion: -g: set gap_count by broadcasting phy_config packet or maybe just: -g: set gap_count > -f: broadcast force_root by phy_config packet Suggestion: -f force a node to become the root node by broadcasting phy_config packet or maybe just: -f force a node to become the root node 7.0 AMD64 # ./fwcontrol -f -5 fwcontrol: main:set_root_node out of range: No such file or directory "No such file or directory" seems wrong 7.0 AMD64 # ./fwcontrol -g 70 fwcontrol: main:set_gap_count out of range: No such file or directory "No such file or directory" seems wrong 7.0 AMD64 # ./fwcontrol -d 70 fwcontrol: no such node -1. (a) 70 becomes -1 ? (b) Wouldn't -d have the same range as -f ? 7.0 AMD64 # ./fwcontrol -c 70 fwcontrol: no such node -1. (a) 70 becomes -1 ? (b) Wouldn't -c have the same range as -f ? 7.0 AMD64 # ./fwcontrol -o 70 fwcontrol: main: node out of range: 70 : No such file or directory "No such file or directory" seems wrong 7.0 AMD64 # ./fwcontrol -s 70 fwcontrol: main: node out of range: 70 : No such file or directory "No such file or directory" seems wrong - asyreq->pkt.mode.ld[1] |= (root_node & 0x3f) << 24 | 1 << 23; + asyreq->pkt.mode.ld[1] |= ((root_node << 24) | (1 << 23)); if (gap_count >= 0) - asyreq->pkt.mode.ld[1] |= 1 << 22 | (gap_count & 0x3f) << 16; + asyreq->pkt.mode.ld[1] |= ((1 << 22) | (gap_count << 16)); Any reason for pulling out the "& 0x3f" ? Yeah it should be redundant now that there is range checking on the arguments, but as you said, fwcontrol is dangerous and the mask makes it safer at very little cost. - for (i = 0; i < 4; i++) { - snprintf(name, sizeof(name), "%s.%d", devbase, i); - if ((*fd = open(name, O_RDWR)) >= 0) - break; - } + *fd = open(devname, O_RDWR); Looking at various firewire man pages, I don't find any explanation of the various /dev filenames, such as what the .%d part was/is for. So I have no clue why this code was changed. Did I miss a discussion? From freebsd at sopwith.solgatos.com Sun Aug 31 20:06:42 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Sun Aug 31 20:06:51 2008 Subject: New and improved? patch In-Reply-To: Your message of "Sun, 31 Aug 2008 12:34:34 BST." Message-ID: <200808312005.UAA08072@sopwith.solgatos.com> > 7.0 AMD64 # ./fwcontrol -f -5 > fwcontrol: main:set_root_node out of range: No such file or directory > > "No such file or directory" seems wrong err(EX_USAGE, "%s:set_root_node out of range", __func__); Err() is correct for places where errno would be set, such as checking the return code from read(2). But for the range checks, errno does not apply, so err() gives misleading results. The err(3) man page isn't clear, but it looks like errx(3) is the function you want for the range checks. Changing err() to errx() gives: 7.0 AMD64 # ./fwcontrol -f 70 fwcontrol: main:set_root_node out of range