From bugmaster at FreeBSD.org Mon Dec 1 03:06:54 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Dec 1 03:07:52 2008 Subject: Current problem reports assigned to freebsd-firewire@FreeBSD.org Message-ID: <200812011106.mB1B6s4r052523@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/113785 firewire [firewire] dropouts when playing DV on firewire o kern/74238 firewire [firewire] fw_rcv: unknown response; firewire ad-hoc w 2 problems total. From bugmaster at FreeBSD.org Mon Dec 8 03:06:55 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Dec 8 03:07:44 2008 Subject: Current problem reports assigned to freebsd-firewire@FreeBSD.org Message-ID: <200812081106.mB8B6s9U014236@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/113785 firewire [firewire] dropouts when playing DV on firewire o kern/74238 firewire [firewire] fw_rcv: unknown response; firewire ad-hoc w 2 problems total. From sbruno at miralink.com Thu Dec 11 13:28:38 2008 From: sbruno at miralink.com (Sean Bruno) Date: Thu Dec 11 13:28:44 2008 Subject: patch for fwcontrol In-Reply-To: <200811101717.RAA12234@sopwith.solgatos.com> References: <200811101717.RAA12234@sopwith.solgatos.com> Message-ID: <494183A4.8060608@miralink.com> Dieter wrote: > In message <4905EE3A.1050506@miralink.com>, Sean Bruno writes: > > >> Dieter wrote: >> >>> The patch below: >>> >>> Fixes several err() vs errx() errors >>> Improves some range checks >>> Improves some messages >>> Supports NetBSD in addition to FreeBSD >>> >>> >> Ok, slightly reworked patch. Seems to work fine for me. Comments? >> > > Sean, > > Sorry for the delay, my normal outgoing email is hosed at > the moment due to some problems upstream, so I'm trying workarounds > with varying success. Incoming email is fine. > > Your version of the patch looks fine, although leaving out > the ".0" of the device name will keep it from working on NetBSD. > > What do you think of something like > > #if defined(__FreeBSD__) > snprintf(devbase, sizeof(devbase), "%s%d", device_string, current_board); > #elif defined(__NetBSD__) > snprintf(devbase, sizeof(devbase), "%s%d.0", device_string, current_board); > #else > #warning "You need to add support for your OS" > #endif > > > This make the code a bit messier, and FreeBSD works fine with the extra ".0" > which is why I just added the ".0". I still don't know what the ".0" was/is for. > > So I see three options: > > 1) Check your patch in as is. NetBSDers will have to modify something. > > 2) Add the ".0". Obviously you don't like this option. > > 3) Put in the #if stuff as above. > > I'd prefer #2 or #3, but if you prefer #1 that's ok. > > thanks, > Dieter > Dieter: It's been a while, but I've finally found some time to revisit this code. I've looked over the firewire driver in FreeBSD and see no reason to use /dev/fw0.0 as the device as /dev/fw0 is just an alias for it. So, with a little more verbose error reporting with regards to permissions(non root opens) here is an updated patch. -- 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: fwmpegts.c =================================================================== --- fwmpegts.c (revision 185940) +++ fwmpegts.c (working copy) @@ -52,9 +52,17 @@ #include #include +#if defined(__FreeBSD__) #include #include +#elif defined(__NetBSD__) +#include +#include +#else +#warning "You need to add support for your OS" +#endif + #include "fwmethods.h" #define DEBUG 0 Index: fwcontrol.c =================================================================== --- fwcontrol.c (revision 185940) +++ fwcontrol.c (working copy) @@ -32,8 +32,10 @@ * SUCH DAMAGE. */ +#if defined(__FreeBSD__) #include __FBSDID("$FreeBSD$"); +#endif #include #include @@ -42,12 +44,23 @@ #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 #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" @@ -78,14 +91,15 @@ "\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-g: set gap count\n" + "\t-f: force root node\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"); - exit(EX_USAGE); + "\t-m: set fwmem target\n" + , getprogname() ); + fprintf(stderr, "\n"); } static void @@ -488,7 +502,7 @@ int len=1024, i; if ((file = fopen(filename, "r")) == NULL) - err(1, "load_crom"); + err(1, "load_crom %s", filename); for (i = 0; i < len/(4*8); i ++) { fscanf(file, DUMP_FORMAT, p, p+1, p+2, p+3, p+4, p+5, p+6, p+7); @@ -691,7 +705,7 @@ */ len = read(fd, buf, RECV_NUM_PACKET * RECV_PACKET_SZ); if (len < 0) - err(EX_IOERR, "%s: error reading from device\n", __func__); + err(EX_IOERR, "%s: error reading from device", __func__); ptr = (u_int32_t *) buf; ciph = (struct ciphdr *)(ptr + 1); @@ -757,10 +771,12 @@ if (argc < 2) { for (current_board = 0; current_board < MAX_BOARDS; current_board++) { - snprintf(devbase, sizeof(devbase), "%s%d", device_string, current_board); + snprintf(devbase, sizeof(devbase), "%s%d.0", device_string, current_board); if (open_dev(&fd, devbase) < 0) { if (current_board == 0) { usage(); + err(EX_IOERR, "%s: Error opening firewire controller #%d %s", + __func__, current_board, devbase); } return(EIO); } @@ -777,7 +793,7 @@ case 'b': priority_budget = strtol(optarg, NULL, 0); if (priority_budget < 0 || priority_budget > INT32_MAX) - errx(EX_USAGE, "%s: invalid number: %s", __func__, optarg); + errx(EX_USAGE, "%s: priority_budget out of range: %s", __func__, optarg); command_set = true; open_needed = true; display_board_only = false; @@ -787,7 +803,7 @@ 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__); + errx(EX_USAGE, "%s:Invalid value for node", __func__); strcpy(crom_string, optarg); display_crom = 1; open_needed = true; @@ -808,7 +824,7 @@ #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__); + errx(EX_USAGE, "%s:set_root_node out of range", __func__); open_needed = true; command_set = true; display_board_only = false; @@ -816,7 +832,7 @@ case 'g': 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__); + errx(EX_USAGE, "%s:set_gap_count out of range", __func__); open_needed = true; command_set = true; display_board_only = false; @@ -834,12 +850,12 @@ display_board_only = false; if (eui64_hostton(optarg, &target) != 0 && eui64_aton(optarg, &target) != 0) - err(EX_USAGE, "%s: invalid target: %s", __func__, optarg); + errx(EX_USAGE, "%s: invalid target: %s", __func__, optarg); break; case 'o': 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); + if ( (send_link_on < 0) || (send_link_on > MAX_PHY_CONFIG) ) + errx(EX_USAGE, "%s: node out of range: %s\n",__func__, optarg); open_needed = true; command_set = true; display_board_only = false; @@ -858,8 +874,8 @@ break; case 's': 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); + if ( (send_reset_start < 0) || (send_reset_start > MAX_PHY_CONFIG) ) + errx(EX_USAGE, "%s: node out of range: %s\n", __func__, optarg); open_needed = true; command_set = true; display_board_only = false; @@ -924,9 +940,9 @@ * */ if(open_needed){ - snprintf(devbase, sizeof(devbase), "%s%d", device_string, current_board); + snprintf(devbase, sizeof(devbase), "%s%d.0", device_string, current_board); if (open_dev(&fd, devbase) < 0) { - errx(EX_IOERR, "%s: Error opening board #%d\n", __func__, current_board); + err(EX_IOERR, "%s: Error opening firewire controller #%d %s", __func__, current_board, devbase); } } /* @@ -996,8 +1012,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 + } /* @@ -1028,9 +1052,9 @@ recvfn = detect_recv_fn(fd, TAG | CHANNEL); close(fd); } - snprintf(devbase, sizeof(devbase), "%s%d", device_string, current_board); + snprintf(devbase, sizeof(devbase), "%s%d.0", 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); + err(EX_IOERR, "%s: Error opening firewire controller #%d %s in recv_data\n", __func__, current_board, devbase); (*recvfn)(fd, recv_data, TAG | CHANNEL, -1); free(recv_data); } From sbruno at miralink.com Thu Dec 11 15:10:20 2008 From: sbruno at miralink.com (Sean Bruno) Date: Thu Dec 11 15:10:27 2008 Subject: patch for fwcontrol In-Reply-To: <494183A4.8060608@miralink.com> References: <200811101717.RAA12234@sopwith.solgatos.com> <494183A4.8060608@miralink.com> Message-ID: <49419DDB.3080900@miralink.com> Sean Bruno wrote: > Dieter wrote: >> In message <4905EE3A.1050506@miralink.com>, Sean Bruno writes: >> >> >>> Dieter wrote: >>> >>>> The patch below: >>>> >>>> Fixes several err() vs errx() errors >>>> Improves some range checks >>>> Improves some messages >>>> Supports NetBSD in addition to FreeBSD >>>> >>> Ok, slightly reworked patch. Seems to work fine for me. Comments? >>> >> >> Sean, >> >> Sorry for the delay, my normal outgoing email is hosed at >> the moment due to some problems upstream, so I'm trying workarounds >> with varying success. Incoming email is fine. >> >> Your version of the patch looks fine, although leaving out >> the ".0" of the device name will keep it from working on NetBSD. >> >> What do you think of something like >> >> #if defined(__FreeBSD__) >> snprintf(devbase, sizeof(devbase), "%s%d", device_string, >> current_board); >> #elif defined(__NetBSD__) >> snprintf(devbase, sizeof(devbase), "%s%d.0", device_string, >> current_board); >> #else >> #warning "You need to add support for your OS" >> #endif >> >> >> This make the code a bit messier, and FreeBSD works fine with the >> extra ".0" >> which is why I just added the ".0". I still don't know what the ".0" >> was/is for. >> >> So I see three options: >> >> 1) Check your patch in as is. NetBSDers will have to modify >> something. >> >> 2) Add the ".0". Obviously you don't like this option. >> >> 3) Put in the #if stuff as above. >> >> I'd prefer #2 or #3, but if you prefer #1 that's ok. >> >> thanks, >> Dieter >> > Dieter: > > It's been a while, but I've finally found some time to revisit this > code. I've looked over the firewire driver > in FreeBSD and see no reason to use /dev/fw0.0 as the device as > /dev/fw0 is just an alias for it. > > So, with a little more verbose error reporting with regards to > permissions(non root opens) here is an updated > patch. > > Ah, and then I go and start changing stuff. This patch adds some useful error output to indicate to the user that the command line args are wrong. This should apply against HEAD. -- 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: fwmpegts.c =================================================================== --- fwmpegts.c (revision 185940) +++ fwmpegts.c (working copy) @@ -52,9 +52,17 @@ #include #include +#if defined(__FreeBSD__) #include #include +#elif defined(__NetBSD__) +#include +#include +#else +#warning "You need to add support for your OS" +#endif + #include "fwmethods.h" #define DEBUG 0 Index: fwcontrol.c =================================================================== --- fwcontrol.c (revision 185940) +++ fwcontrol.c (working copy) @@ -32,8 +32,10 @@ * SUCH DAMAGE. */ +#if defined(__FreeBSD__) #include __FBSDID("$FreeBSD$"); +#endif #include #include @@ -42,12 +44,23 @@ #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 #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" @@ -78,14 +91,15 @@ "\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-g: set gap count\n" + "\t-f: force root node\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"); - exit(EX_USAGE); + "\t-m: set fwmem target\n" + , getprogname() ); + fprintf(stderr, "\n"); } static void @@ -488,7 +502,7 @@ int len=1024, i; if ((file = fopen(filename, "r")) == NULL) - err(1, "load_crom"); + err(1, "load_crom %s", filename); for (i = 0; i < len/(4*8); i ++) { fscanf(file, DUMP_FORMAT, p, p+1, p+2, p+3, p+4, p+5, p+6, p+7); @@ -691,7 +705,7 @@ */ len = read(fd, buf, RECV_NUM_PACKET * RECV_PACKET_SZ); if (len < 0) - err(EX_IOERR, "%s: error reading from device\n", __func__); + err(EX_IOERR, "%s: error reading from device", __func__); ptr = (u_int32_t *) buf; ciph = (struct ciphdr *)(ptr + 1); @@ -757,10 +771,12 @@ if (argc < 2) { for (current_board = 0; current_board < MAX_BOARDS; current_board++) { - snprintf(devbase, sizeof(devbase), "%s%d", device_string, current_board); + snprintf(devbase, sizeof(devbase), "%s%d.0", device_string, current_board); if (open_dev(&fd, devbase) < 0) { if (current_board == 0) { usage(); + err(EX_IOERR, "%s: Error opening firewire controller #%d %s", + __func__, current_board, devbase); } return(EIO); } @@ -777,7 +793,7 @@ case 'b': priority_budget = strtol(optarg, NULL, 0); if (priority_budget < 0 || priority_budget > INT32_MAX) - errx(EX_USAGE, "%s: invalid number: %s", __func__, optarg); + errx(EX_USAGE, "%s: priority_budget out of range: %s", __func__, optarg); command_set = true; open_needed = true; display_board_only = false; @@ -787,7 +803,7 @@ 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__); + errx(EX_USAGE, "%s:Invalid value for node", __func__); strcpy(crom_string, optarg); display_crom = 1; open_needed = true; @@ -808,7 +824,7 @@ #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__); + errx(EX_USAGE, "%s:set_root_node out of range", __func__); open_needed = true; command_set = true; display_board_only = false; @@ -816,7 +832,7 @@ case 'g': 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__); + errx(EX_USAGE, "%s:set_gap_count out of range", __func__); open_needed = true; command_set = true; display_board_only = false; @@ -834,12 +850,12 @@ display_board_only = false; if (eui64_hostton(optarg, &target) != 0 && eui64_aton(optarg, &target) != 0) - err(EX_USAGE, "%s: invalid target: %s", __func__, optarg); + errx(EX_USAGE, "%s: invalid target: %s", __func__, optarg); break; case 'o': 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); + if ( (send_link_on < 0) || (send_link_on > MAX_PHY_CONFIG) ) + errx(EX_USAGE, "%s: node out of range: %s\n",__func__, optarg); open_needed = true; command_set = true; display_board_only = false; @@ -858,8 +874,8 @@ break; case 's': 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); + if ( (send_reset_start < 0) || (send_reset_start > MAX_PHY_CONFIG) ) + errx(EX_USAGE, "%s: node out of range: %s\n", __func__, optarg); open_needed = true; command_set = true; display_board_only = false; @@ -909,13 +925,27 @@ command_set = true; display_board_only = false; break; + case '?': default: usage(); + warnc(EINVAL, "%s: Unknown command line arguments", __func__); return 0; } } /* end while */ /* + * Catch the error case when the user + * executes the command with non ''-'' + * delimited arguments. + * Generate the usage() display and exit. + */ + if (!command_set && !display_board_only) { + usage(); + warnc(EINVAL, "%s: Unknown command line arguments", __func__); + return 0; + } + + /* * If -u is passed, execute * command for that card only. * @@ -924,9 +954,9 @@ * */ if(open_needed){ - snprintf(devbase, sizeof(devbase), "%s%d", device_string, current_board); + snprintf(devbase, sizeof(devbase), "%s%d.0", device_string, current_board); if (open_dev(&fd, devbase) < 0) { - errx(EX_IOERR, "%s: Error opening board #%d\n", __func__, current_board); + err(EX_IOERR, "%s: Error opening firewire controller #%d %s", __func__, current_board, devbase); } } /* @@ -947,7 +977,7 @@ */ if (send_bus_reset) { if(ioctl(fd, FW_IBUSRST, &tmp) < 0) - err(EX_IOERR, "%s: ioctl", __func__); + err(EX_IOERR, "%s: Ioctl of bus reset failed for %s", __func__, devbase); } /* * Print out the CROM for this node "-c" @@ -996,8 +1026,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 + } /* @@ -1028,9 +1066,9 @@ recvfn = detect_recv_fn(fd, TAG | CHANNEL); close(fd); } - snprintf(devbase, sizeof(devbase), "%s%d", device_string, current_board); + snprintf(devbase, sizeof(devbase), "%s%d.0", 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); + err(EX_IOERR, "%s: Error opening firewire controller #%d %s in recv_data\n", __func__, current_board, devbase); (*recvfn)(fd, recv_data, TAG | CHANNEL, -1); free(recv_data); } From freebsd at sopwith.solgatos.com Thu Dec 11 21:08:06 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Thu Dec 11 21:08:11 2008 Subject: patch for fwcontrol In-Reply-To: Your message of "Thu, 11 Dec 2008 15:10:19 PST." <49419DDB.3080900@miralink.com> Message-ID: <200812120050.AAA09682@sopwith.solgatos.com> > Ah, and then I go and start changing stuff. Quick! Check it in before one of us gets another idea of something to change! :-) From bugmaster at FreeBSD.org Mon Dec 15 03:06:51 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Dec 15 03:07:51 2008 Subject: Current problem reports assigned to freebsd-firewire@FreeBSD.org Message-ID: <200812151106.mBFB6oEP004305@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/113785 firewire [firewire] dropouts when playing DV on firewire o kern/74238 firewire [firewire] fw_rcv: unknown response; firewire ad-hoc w 2 problems total. From freebsd at sopwith.solgatos.com Mon Dec 15 21:10:10 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Mon Dec 15 21:10:16 2008 Subject: kern/118093: firewire bus reset hogs CPU, causing data to be lost Message-ID: <200812150330.DAA27074@sopwith.solgatos.com> I found the source of this problem. When a firewire bus resets, the firewire driver prints a few lines to the console, using printf(9) and device_printf(9). I suspect that these are running at splfw aka splimp, locking out other i/o. Commenting out the *printf() calls fixes the problem, but that isn't a good solution. Would changing the *printf() calls to log(9) calls be safe? ("safe" meaning other i/o doesn't get locked out) Ah, for the good old days when 19200 baud seemed fast... From sbruno at miralink.com Mon Dec 15 21:14:34 2008 From: sbruno at miralink.com (Sean Bruno) Date: Mon Dec 15 21:14:39 2008 Subject: kern/118093: firewire bus reset hogs CPU, causing data to be lost In-Reply-To: <200812150330.DAA27074@sopwith.solgatos.com> References: <200812150330.DAA27074@sopwith.solgatos.com> Message-ID: <49473938.80906@miralink.com> Dieter wrote: > I found the source of this problem. When a firewire bus resets, > the firewire driver prints a few lines to the console, > using printf(9) and device_printf(9). I suspect that these are > running at splfw aka splimp, locking out other i/o. > > Commenting out the *printf() calls fixes the problem, but that > isn't a good solution. > > Would changing the *printf() calls to log(9) calls be safe? > ("safe" meaning other i/o doesn't get locked out) > > Ah, for the good old days when 19200 baud seemed fast... > _______________________________________________ > Which one are you looking at Dieter? Sean From ikob at ni.aist.go.jp Mon Dec 15 21:35:08 2008 From: ikob at ni.aist.go.jp (Katsushi Kobayashi) Date: Mon Dec 15 21:35:40 2008 Subject: kern/118093: firewire bus reset hogs CPU, causing data to be lost In-Reply-To: <200812150330.DAA27074@sopwith.solgatos.com> References: <200812150330.DAA27074@sopwith.solgatos.com> Message-ID: <15EB8FB3-CAA8-4834-9979-912508B619D4@ni.aist.go.jp> Hi, I believe no side effect is anticipated the message. "side effect" includes locking i/o. ---- Katsushi Kobayashi On 2008/12/15, at 4:30, Dieter wrote: > I found the source of this problem. When a firewire bus resets, > the firewire driver prints a few lines to the console, > using printf(9) and device_printf(9). I suspect that these are > running at splfw aka splimp, locking out other i/o. > > Commenting out the *printf() calls fixes the problem, but that > isn't a good solution. > > Would changing the *printf() calls to log(9) calls be safe? > ("safe" meaning other i/o doesn't get locked out) > > Ah, for the good old days when 19200 baud seemed fast... > _______________________________________________ > freebsd-firewire@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-firewire > To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@freebsd.org" From imp at bsdimp.com Mon Dec 15 22:03:20 2008 From: imp at bsdimp.com (Warner Losh) Date: Mon Dec 15 22:03:27 2008 Subject: kern/118093: firewire bus reset hogs CPU, causing data to be lost In-Reply-To: <200812150330.DAA27074@sopwith.solgatos.com> References: <200812150330.DAA27074@sopwith.solgatos.com> Message-ID: <20081215.230130.74702477.imp@bsdimp.com> > I found the source of this problem. When a firewire bus resets, > the firewire driver prints a few lines to the console, > using printf(9) and device_printf(9). I suspect that these are > running at splfw aka splimp, locking out other i/o. This can't be the case. There's no SPL involved at all. Maybe removing the printfs causes an interrupt to be serviced faster, resulting in what appears to be better performance... > Commenting out the *printf() calls fixes the problem, but that > isn't a good solution. > > Would changing the *printf() calls to log(9) calls be safe? > ("safe" meaning other i/o doesn't get locked out) > > Ah, for the good old days when 19200 baud seemed fast... > _______________________________________________ > freebsd-drivers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-drivers > To unsubscribe, send any mail to "freebsd-drivers-unsubscribe@freebsd.org" > > From freebsd at sopwith.solgatos.com Tue Dec 16 21:10:24 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Tue Dec 16 21:10:30 2008 Subject: kern/118093: firewire bus reset hogs CPU, causing data to be lost In-Reply-To: Your message of "Tue, 16 Dec 2008 09:51:44 PST." <4947EAB0.3020704@miralink.com> Message-ID: <200812170329.DAA17848@sopwith.solgatos.com> Sean> Which file in dev/firewire are you looking at? fwohci.c and firewire.c examples: printf("non CYCLEMASTER mode\n"); device_printf(fc->dev, "Initiate bus reset\n"); ------------------- Warner> This can't be the case. There's no SPL involved at all. Maybe Warner> removing the printfs causes an interrupt to be serviced faster, Warner> resulting in what appears to be better performance... With the printfs, Ethernet is not getting serviced. This is repeatable and easily reproduced. Without the printfs, it seems ok. If it isn't spl, what is locking out Ethernet? From imp at bsdimp.com Tue Dec 16 23:00:26 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Dec 16 23:00:32 2008 Subject: kern/118093: firewire bus reset hogs CPU, causing data to be lost In-Reply-To: <200812170329.DAA17848@sopwith.solgatos.com> References: <4947EAB0.3020704@miralink.com> <200812170329.DAA17848@sopwith.solgatos.com> Message-ID: <20081216.235941.1266245051.imp@bsdimp.com> In message: <200812170329.DAA17848@sopwith.solgatos.com> Dieter writes: : Sean> Which file in dev/firewire are you looking at? : : fwohci.c and firewire.c : : examples: : : printf("non CYCLEMASTER mode\n"); : : device_printf(fc->dev, "Initiate bus reset\n"); : : ------------------- : : Warner> This can't be the case. There's no SPL involved at all. Maybe : Warner> removing the printfs causes an interrupt to be serviced faster, : Warner> resulting in what appears to be better performance... : : With the printfs, Ethernet is not getting serviced. This : is repeatable and easily reproduced. Without the printfs, : it seems ok. : : If it isn't spl, what is locking out Ethernet? interrupt storm? In old-spl-locked drivers, often times the interrupt would be masked while certain operations happened. In new mutex-locked freebsd, there's no way to block the interrupts, so sometimes old code gets into an interrupt storm, which starves other things. Not sure why printf would trigger this, however... Warner From sbruno at miralink.com Wed Dec 17 17:10:57 2008 From: sbruno at miralink.com (Sean Bruno) Date: Wed Dec 17 17:11:03 2008 Subject: kern/118093: firewire bus reset hogs CPU, causing data to be lost In-Reply-To: <20081216.235941.1266245051.imp@bsdimp.com> References: <4947EAB0.3020704@miralink.com> <200812170329.DAA17848@sopwith.solgatos.com> <20081216.235941.1266245051.imp@bsdimp.com> Message-ID: <4949A31D.5030507@miralink.com> M. Warner Losh wrote: > In message: <200812170329.DAA17848@sopwith.solgatos.com> > Dieter writes: > : Sean> Which file in dev/firewire are you looking at? > : > : fwohci.c and firewire.c > : > : examples: > : > : printf("non CYCLEMASTER mode\n"); > : > : device_printf(fc->dev, "Initiate bus reset\n"); > : > : ------------------- > : > : Warner> This can't be the case. There's no SPL involved at all. Maybe > : Warner> removing the printfs causes an interrupt to be serviced faster, > : Warner> resulting in what appears to be better performance... > : > : With the printfs, Ethernet is not getting serviced. This > : is repeatable and easily reproduced. Without the printfs, > : it seems ok. > : > : If it isn't spl, what is locking out Ethernet? > > interrupt storm? In old-spl-locked drivers, often times the interrupt > would be masked while certain operations happened. In new > mutex-locked freebsd, there's no way to block the interrupts, so > sometimes old code gets into an interrupt storm, which starves other > things. Not sure why printf would trigger this, however... > > Warner > _______________________________________________ > freebsd-drivers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-drivers > To unsubscribe, send any mail to "freebsd-drivers-unsubscribe@freebsd.org" > Let me take a stab at this one this week. There's got to be something more going on than a printf() causing hell. It could be a mutex being held causing nightmares. The firewire code is my current project, I'll look at this issue now. Sean From freebsd at sopwith.solgatos.com Thu Dec 18 00:53:39 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Thu Dec 18 00:53:46 2008 Subject: kern/118093: firewire bus reset hogs CPU, causing data to be lost In-Reply-To: Your message of "Wed, 17 Dec 2008 17:10:53 PST." <4949A31D.5030507@miralink.com> Message-ID: <200812180851.IAA08485@sopwith.solgatos.com> > > : Warner> This can't be the case. There's no SPL involved at all. Maybe > > : Warner> removing the printfs causes an interrupt to be serviced faster, > > : Warner> resulting in what appears to be better performance... > > : > > : With the printfs, Ethernet is not getting serviced. This > > : is repeatable and easily reproduced. Without the printfs, > > : it seems ok. > > : > > : If it isn't spl, what is locking out Ethernet? > > > > interrupt storm? In old-spl-locked drivers, often times the interrupt > > would be masked while certain operations happened. In new > > mutex-locked freebsd, there's no way to block the interrupts, so > > sometimes old code gets into an interrupt storm, which starves other > > things. Not sure why printf would trigger this, however... I tried logging in on the console and "cat /etc/termcap" does not create a problem. Systat -vmstat reports that IRQ 5 (console) interrupts go from 0 to 120. CPU: 0.0%Sys 0.6%Intr 0.0%User 0.0%Nice 99.4%Idle The normal firewire bus reset printfs generate 890 IRQ 5 interrupts with the shell firing off "fwcontrol -u 1 -r" in a loop. CPU goes from idle to 100% busy: 98.1%Sys 1.7%Intr 0.3%User 0.0%Nice 0.0%Idle "fwcontrol -u 0 -r" (the onboard firewire controller) gives the same 890 IRQ 5 interrupts, but CPU usage is different: 79.2%Sys 20.8%Intr 0.0%User 0.0%Nice 0.0%Idle A couple of other IRQs go up to 30-40 range, nothing huge. A single "fwcontrol -u 0 -r" generates 14 interrupts on IRQ 5 and 4 interrupts on 3 other IRQs. A single "fwcontrol -u 1 -r" generates 14 interrupts on IRQ 5 and 3 interrupts on 2 other IRQs. yawn ------ With the bus reset printfs commented out, I get: -u 0 80.0%Sys 4.8%Intr 13.9%User 0.0%Nice 1.2%Idle 3300 interrupts on the onboard firewire controller -u 1 84.8%Sys 1.1%Intr 14.1%User 0.0%Nice 0.0%Idle 3900 interrupts on the PCI card firewire controller After awhile the console says: fwohci1: phy read failed(1). i = 100 retry = 0 fwohci1: phy read failed(1). i = 100 retry = 1 fwohci1: phy read failed(1). i = 100 retry = 2 fwohci1: phy read failed(1). i = 100 retry = 3 ... and the system becomes unresponsive. Reset button required. :-( Observations: Kernel printfs to console appear to take more interrupts and more CPU than userland output to console. Seems odd that the onboard controller uses so much CPU for interrupts in the with-printf case, but there wasn't a large number on interrupts. The without-printf case had a LOT more interrupts from the fw controller. Resetting the firewire bus in an endless loop is not recommended. I'm not an expert on interrupt storms, but none of this looks like an interrupt storm to me. (Assuming systat is trustworthy.) Looks like the kernel printf takes a *lot* of CPU, and somehow locks out Ethernet. From freebsd at sopwith.solgatos.com Fri Dec 19 21:14:24 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Fri Dec 19 21:14:30 2008 Subject: kern/118093: firewire bus reset hogs CPU, causing data to be lost Message-ID: <200812191902.TAA01939@sopwith.solgatos.com> Here are the results of two more experiments: I tried to verify what spl the firewire code is at when calling printf(9) by adding the following block into fwohci.c just before one of the printfs. { #include #include intrmask_t debug_spl; /* __uint32_t */ intrmask_t debug_spl_high; intrmask_t debug_spl_tty; intrmask_t debug_spl_fw; intrmask_t debug_spl_0; intrmask_t debug_spl_net; debug_spl = splhigh(); debug_spl_high = spltty(); debug_spl_tty = splfw(); debug_spl_fw = splnet(); debug_spl_net = splhigh(); spl0(); /* void */ debug_spl_0 = splhigh(); splx(debug_spl); printf("fwohci_intr_core(): spl = 0x%x\n splhigh=0x%x spltty=0x%x splfw=0x%x splnet=0x%x spl0=0x%x\n", debug_spl, debug_spl_high, debug_spl_tty, debug_spl_fw, debug_spl_net, debug_spl_0); } But my results appear bogus: fwohci_intr_core(): spl = 0x0 splhigh=0x0 spltty=0x0 splfw=0x0 splnet=0x0 spl0=0x0 I have examined my code and the spl(9) man page several times but I can't find what is wrong. Any clues? -------------------------------------------------------- To isolate the effects of printf(9) from the firewire bus reset, I picked a trivial system call (chown(2)) and added some printf(9) calls. Calling chown several times and monitoring with systat -vmstat gives: 1098 interrupts on the console IRQ 93.1%Sys 6.7%Intr 0.2%User 0.0%Nice 0.0%Idle This did NOT interfere with Ethernet. So printf(9) interferes with Ethernet when called from the firewire driver, but not when called from a vanilla system call. -------------------------------------------------------- sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio0: [FILTER] What does [FILTER] mean? I don't see an explanation on the sio man page. From sbruno at miralink.com Sat Dec 20 18:49:22 2008 From: sbruno at miralink.com (Sean Bruno) Date: Sat Dec 20 18:49:29 2008 Subject: kern/118093: firewire bus reset hogs CPU, causing data to be lost In-Reply-To: <200812191902.TAA01939@sopwith.solgatos.com> References: <200812191902.TAA01939@sopwith.solgatos.com> Message-ID: <494DAEB1.1070909@miralink.com> Dieter wrote: > Here are the results of two more experiments: > > I tried to verify what spl the firewire code is at when calling > printf(9) by adding the following block into fwohci.c just > before one of the printfs. > > { > #include > #include > intrmask_t debug_spl; /* __uint32_t */ > intrmask_t debug_spl_high; > intrmask_t debug_spl_tty; > intrmask_t debug_spl_fw; > intrmask_t debug_spl_0; > intrmask_t debug_spl_net; > > debug_spl = splhigh(); > debug_spl_high = spltty(); > debug_spl_tty = splfw(); > debug_spl_fw = splnet(); > debug_spl_net = splhigh(); > spl0(); /* void */ > debug_spl_0 = splhigh(); > splx(debug_spl); > > printf("fwohci_intr_core(): spl = 0x%x\n splhigh=0x%x spltty=0x%x splfw=0x%x splnet=0x%x spl0=0x%x\n", > debug_spl, debug_spl_high, debug_spl_tty, debug_spl_fw, debug_spl_net, debug_spl_0); > } > > But my results appear bogus: > > fwohci_intr_core(): spl = 0x0 > splhigh=0x0 spltty=0x0 splfw=0x0 splnet=0x0 spl0=0x0 > > I have examined my code and the spl(9) man page several times > but I can't find what is wrong. Any clues? > > -------------------------------------------------------- > > To isolate the effects of printf(9) from the firewire bus reset, > I picked a trivial system call (chown(2)) and added some printf(9) > calls. > > Calling chown several times and monitoring with systat -vmstat gives: > 1098 interrupts on the console IRQ > 93.1%Sys 6.7%Intr 0.2%User 0.0%Nice 0.0%Idle > > This did NOT interfere with Ethernet. > > So printf(9) interferes with Ethernet when called from the > firewire driver, but not when called from a vanilla system call. > > I setup my system to execute a bus reset every 1 second, simultaneously, I started copying a large file onto the system see if anything would happen. I saw no change to copy speed reported by SCP during the entire transaction. I also see no change to the system load while this is occurring. This seems indicative of "something else" going on. > -------------------------------------------------------- > > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > sio0: type 16550A, console > sio0: [FILTER] > > What does [FILTER] mean? I don't see an explanation on the sio man page. > Did you mean to ask a different list? Because I have no idea. :) From freebsd at sopwith.solgatos.com Sat Dec 20 21:27:02 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Sat Dec 20 21:27:09 2008 Subject: kern/118093: firewire bus reset hogs CPU, causing data to be lost In-Reply-To: Your message of "Sat, 20 Dec 2008 18:49:21 PST." <494DAEB1.1070909@miralink.com> Message-ID: <200812210524.FAA02070@sopwith.solgatos.com> In message <494DAEB1.1070909@miralink.com>, Sean Bruno writes: > I setup my system to execute a bus reset every 1 second, simultaneously, > I started copying a large > file onto the system see if anything would happen. > > I saw no change to copy speed reported by SCP during the entire > transaction. I also see no change > to the system load while this is occurring. Does your system have a RS-232 console or VGA console? The problem might be specific to RS-232. > This seems indicative of "something else" going on. Any idea what this "something else" might be? Does anyone have a clue why my spl calls are returning 0 ? From bugmaster at FreeBSD.org Mon Dec 22 03:06:50 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Dec 22 03:07:49 2008 Subject: Current problem reports assigned to freebsd-firewire@FreeBSD.org Message-ID: <200812221106.mBMB6opj060546@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/113785 firewire [firewire] dropouts when playing DV on firewire o kern/74238 firewire [firewire] fw_rcv: unknown response; firewire ad-hoc w 2 problems total. From sbruno at miralink.com Mon Dec 22 19:21:51 2008 From: sbruno at miralink.com (Sean Bruno) Date: Mon Dec 22 19:21:58 2008 Subject: kern/118093: firewire bus reset hogs CPU, causing data to be lost In-Reply-To: <200812210524.FAA02070@sopwith.solgatos.com> References: <200812210524.FAA02070@sopwith.solgatos.com> Message-ID: <4950594D.50208@miralink.com> Dieter wrote: > In message <494DAEB1.1070909@miralink.com>, Sean Bruno writes: > > >> I setup my system to execute a bus reset every 1 second, simultaneously, >> I started copying a large >> file onto the system see if anything would happen. >> >> I saw no change to copy speed reported by SCP during the entire >> transaction. I also see no change >> to the system load while this is occurring. >> > > Does your system have a RS-232 console or VGA console? > The problem might be specific to RS-232. > > I have both. I disabled my serial console to test, no change when using the VGA console only. >> This seems indicative of "something else" going on. >> > > Any idea what this "something else" might be? > > Does anyone have a clue why my spl calls are returning 0 ? > > I confirmed that spl's are complete no-ops since rel 5. So, you want to ignore them as they are just markers now where locking should be implemented. I went back in your original submission and I can see a significant drop in I/O when resetting the F/W bus. If I have the following running: dd if=/dev/zero of=/dev/ad6 bs=64k Then I see about 64MB/S normally. When I reset any firewire bus, I see the throughput drop as reported by iostat by a significant amount(2-4 MB/s). I am assuming that the firewire driver is holding a very heavy lock here that is cascading down to the printf(). At least, that would be my ASSumption. :) I will continue to poke around. You are not crazy Dieter. Sean From sbruno at miralink.com Mon Dec 22 22:01:56 2008 From: sbruno at miralink.com (Sean Bruno) Date: Mon Dec 22 22:02:03 2008 Subject: kern/118093: firewire bus reset hogs CPU, causing data to be lost In-Reply-To: <4950594D.50208@miralink.com> References: <200812210524.FAA02070@sopwith.solgatos.com> <4950594D.50208@miralink.com> Message-ID: <49507ED3.9010006@miralink.com> Sean Bruno wrote: > Dieter wrote: >> In message <494DAEB1.1070909@miralink.com>, Sean Bruno writes: >> >> >>> I setup my system to execute a bus reset every 1 second, >>> simultaneously, I started copying a large >>> file onto the system see if anything would happen. >>> >>> I saw no change to copy speed reported by SCP during the entire >>> transaction. I also see no change >>> to the system load while this is occurring. >>> >> >> Does your system have a RS-232 console or VGA console? >> The problem might be specific to RS-232. >> >> > I have both. I disabled my serial console to test, no change when using > the VGA console only. > >>> This seems indicative of "something else" going on. >>> >> >> Any idea what this "something else" might be? >> >> Does anyone have a clue why my spl calls are returning 0 ? >> >> > I confirmed that spl's are complete no-ops since rel 5. So, you want > to ignore > them as they are just markers now where locking should be implemented. > > I went back in your original submission and I can see a significant > drop in I/O > when resetting the F/W bus. If I have the following running: > dd if=/dev/zero of=/dev/ad6 bs=64k > > Then I see about 64MB/S normally. When I reset any firewire bus, I > see the throughput > drop as reported by iostat by a significant amount(2-4 MB/s). > > I am assuming that the firewire driver is holding a very heavy lock > here that is cascading > down to the printf(). At least, that would be my ASSumption. :) > > I will continue to poke around. You are not crazy Dieter. > > Sean > > Hrm ... Looking over the log messages that are generated during a bus reset, there's a mish-mash of printf() and device_printf() calls. I'm not sure what the impact of that is to real behavior, but /var/log/messages has a tendency to get garbled like this: Dec 22 16:00:18 home-test kernel: fwohci1: Initiate bus reset Dec 22 16:00:18 home-test kernel: fwohci1: BUS reset Dec 22 16:00:18 home-test kernel: fwohci1: node_id=0xc800ffc0, gen=8, CYCLEMASTER mode Dec 22 16:00:18 home-test kernel: firewi Dec 22 16:00:18 home-test kernel: re1: Dec 22 16:00:18 home-test kernel: 1 n Dec 22 16:00:18 home-test kernel: odes Dec 22 16:00:18 home-test kernel: , ma Dec 22 16:00:18 home-test kernel: xhop Dec 22 16:00:18 home-test kernel: <= Dec 22 16:00:18 home-test kernel: 0, c Dec 22 16:00:18 home-test kernel: able Dec 22 16:00:18 home-test kernel: IRM Dec 22 16:00:18 home-test kernel: = 0 Dec 22 16:00:18 home-test kernel: (me Dec 22 16:00:18 home-test kernel: ) Dec 22 16:00:18 home-test kernel: f Dec 22 16:00:18 home-test kernel: irew Dec 22 16:00:18 home-test kernel: ire1 Dec 22 16:00:18 home-test kernel: : bu Dec 22 16:00:18 home-test kernel: s ma Dec 22 16:00:18 home-test kernel: nage Dec 22 16:00:18 home-test kernel: r 0 Dec 22 16:00:18 home-test kernel: (me) Dec 22 16:00:18 home-test kernel: Let me try to eliminate this behaviour first. Sean From freebsd at sopwith.solgatos.com Thu Dec 25 22:25:03 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Thu Dec 25 22:25:34 2008 Subject: kern/118093: firewire bus reset hogs CPU, causing data to be lost In-Reply-To: Your message of "Mon, 22 Dec 2008 22:01:55 PST." <49507ED3.9010006@miralink.com> Message-ID: <200812260623.GAA20643@sopwith.solgatos.com> > > I confirmed that spl's are complete no-ops since rel 5. So, you want > > to ignore > > them as they are just markers now where locking should be implemented. I hunted down the spl code, and you're right. Wow, I wonder how drivers still using spl calls work at all? > is to real behavior, but /var/log/messages has a tendency to get garbled > like this: > > Dec 22 16:00:18 home-test kernel: fwohci1: Initiate bus reset > Dec 22 16:00:18 home-test kernel: fwohci1: BUS reset > Dec 22 16:00:18 home-test kernel: fwohci1: node_id=0xc800ffc0, gen=8, > CYCLEMASTER mode > Dec 22 16:00:18 home-test kernel: firewi > Dec 22 16:00:18 home-test kernel: re1: > Dec 22 16:00:18 home-test kernel: 1 n > Dec 22 16:00:18 home-test kernel: odes > Dec 22 16:00:18 home-test kernel: , ma > Dec 22 16:00:18 home-test kernel: xhop > Dec 22 16:00:18 home-test kernel: <= > Dec 22 16:00:18 home-test kernel: 0, c > Dec 22 16:00:18 home-test kernel: able Do the lines get folded on the console, or only in /var/log/messages? From sbruno at miralink.com Sun Dec 28 14:15:37 2008 From: sbruno at miralink.com (Sean Bruno) Date: Sun Dec 28 14:15:44 2008 Subject: kern/118093: firewire bus reset hogs CPU, causing data to be lost In-Reply-To: <200812260623.GAA20643@sopwith.solgatos.com> References: <200812260623.GAA20643@sopwith.solgatos.com> Message-ID: <4957FA88.1000604@miralink.com> Dieter wrote: >>> I confirmed that spl's are complete no-ops since rel 5. So, you want >>> to ignore >>> them as they are just markers now where locking should be implemented. >>> > > I hunted down the spl code, and you're right. Wow, I wonder how drivers > still using spl calls work at all? > > I believe that the spl() calls are just left there as a hint where locking should be. As far as I understand, we need to pay attention to the mutex locks. >> is to real behavior, but /var/log/messages has a tendency to get garbled >> like this: >> >> Dec 22 16:00:18 home-test kernel: fwohci1: Initiate bus reset >> Dec 22 16:00:18 home-test kernel: fwohci1: BUS reset >> Dec 22 16:00:18 home-test kernel: fwohci1: node_id=0xc800ffc0, gen=8, >> CYCLEMASTER mode >> Dec 22 16:00:18 home-test kernel: firewi >> Dec 22 16:00:18 home-test kernel: re1: >> Dec 22 16:00:18 home-test kernel: 1 n >> Dec 22 16:00:18 home-test kernel: odes >> Dec 22 16:00:18 home-test kernel: , ma >> Dec 22 16:00:18 home-test kernel: xhop >> Dec 22 16:00:18 home-test kernel: <= >> Dec 22 16:00:18 home-test kernel: 0, c >> Dec 22 16:00:18 home-test kernel: able >> > > Do the lines get folded on the console, or only in /var/log/messages? > As far as I can see, the console messages are fine. It's only the messages that get garbled. Sean From freebsd at sopwith.solgatos.com Sun Dec 28 21:51:21 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Sun Dec 28 21:51:27 2008 Subject: kern/118093: firewire bus reset hogs CPU, causing data to be lost In-Reply-To: Your message of "Sun, 28 Dec 2008 14:15:36 PST." <4957FA88.1000604@miralink.com> Message-ID: <200812290549.FAA02342@sopwith.solgatos.com> > >>> I confirmed that spl's are complete no-ops since rel 5. So, you want > >>> to ignore > >>> them as they are just markers now where locking should be implemented. > >>> > > > > I hunted down the spl code, and you're right. Wow, I wonder how drivers > > still using spl calls work at all? > > > > > I believe that the spl() calls are just left there as a hint where > locking should be. > > As far as I understand, we need to pay attention to the mutex locks. I'll rephrase my question. In the old days, locking was done with spl. The new way is with mutex. But with the spl calls being replaced with noops, and as far as I can tell the driver is not using mutex, there doesn't appear to be any locking. So the driver can step on itself. > >> is to real behavior, but /var/log/messages has a tendency to get garbled > >> like this: > >> > >> Dec 22 16:00:18 home-test kernel: fwohci1: Initiate bus reset > >> Dec 22 16:00:18 home-test kernel: fwohci1: BUS reset > >> Dec 22 16:00:18 home-test kernel: fwohci1: node_id=0xc800ffc0, gen=8, > >> CYCLEMASTER mode > >> Dec 22 16:00:18 home-test kernel: firewi > >> Dec 22 16:00:18 home-test kernel: re1: > >> Dec 22 16:00:18 home-test kernel: 1 n > >> Dec 22 16:00:18 home-test kernel: odes > >> Dec 22 16:00:18 home-test kernel: , ma > >> Dec 22 16:00:18 home-test kernel: xhop > >> Dec 22 16:00:18 home-test kernel: <= > >> Dec 22 16:00:18 home-test kernel: 0, c > >> Dec 22 16:00:18 home-test kernel: able > >> > > > > Do the lines get folded on the console, or only in /var/log/messages? > > > > As far as I can see, the console messages are fine. It's only the > messages that get > garbled. Perhaps an artifact of syslogd? From sbruno at miralink.com Sun Dec 28 22:22:27 2008 From: sbruno at miralink.com (Sean Bruno) Date: Sun Dec 28 22:22:34 2008 Subject: kern/118093: firewire bus reset hogs CPU, causing data to be lost In-Reply-To: <200812290549.FAA02342@sopwith.solgatos.com> References: <200812290549.FAA02342@sopwith.solgatos.com> Message-ID: <49586CA2.60907@miralink.com> Dieter wrote: >>> >>> >>> >> I believe that the spl() calls are just left there as a hint where >> locking should be. >> >> As far as I understand, we need to pay attention to the mutex locks. >> > > I'll rephrase my question. In the old days, locking was done with spl. > The new way is with mutex. But with the spl calls being replaced with > noops, and as far as I can tell the driver is not using mutex, there > doesn't appear to be any locking. So the driver can step on itself. > > Well, there is locking around a couple of mutex's via FW_GLOCK(). It appears that the locking is not robust, and that is one of the issues that I am looking into right now. > >>>> is to real behavior, but /var/log/messages has a tendency to get garbled >>>> like this: >>>> >>>> Dec 22 16:00:18 home-test kernel: fwohci1: Initiate bus reset >>>> Dec 22 16:00:18 home-test kernel: fwohci1: BUS reset >>>> Dec 22 16:00:18 home-test kernel: fwohci1: node_id=0xc800ffc0, gen=8, >>>> CYCLEMASTER mode >>>> Dec 22 16:00:18 home-test kernel: firewi >>>> Dec 22 16:00:18 home-test kernel: re1: >>>> Dec 22 16:00:18 home-test kernel: 1 n >>>> Dec 22 16:00:18 home-test kernel: odes >>>> Dec 22 16:00:18 home-test kernel: , ma >>>> Dec 22 16:00:18 home-test kernel: xhop >>>> Dec 22 16:00:18 home-test kernel: <= >>>> Dec 22 16:00:18 home-test kernel: 0, c >>>> Dec 22 16:00:18 home-test kernel: able >>>> >>>> >>> Do the lines get folded on the console, or only in /var/log/messages? >>> >>> >> As far as I can see, the console messages are fine. It's only the >> messages that get >> garbled. >> > > Perhaps an artifact of syslogd? > I doubt it. I'm working on a patch that improves the locking a bit and does some other "gross" things to try and keep things from flying apart. I've SEEN this behaviour in my implementations with sbp_targ and couldn't pin it down. Scott Long gave me a couple of pointers this evening, but I'm still working on locking down the taskqueues and some of the callback_handlers. There are some bad things going on specifically during initialization that are pre-empting normal operation. Sean From freebsd at sopwith.solgatos.com Sun Dec 28 23:33:24 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Sun Dec 28 23:33:30 2008 Subject: kern/118093: firewire bus reset hogs CPU, causing data to be lost In-Reply-To: Your message of "Sun, 28 Dec 2008 22:22:26 PST." <49586CA2.60907@miralink.com> Message-ID: <200812290730.HAA23593@sopwith.solgatos.com> > > I'll rephrase my question. In the old days, locking was done with spl. > > The new way is with mutex. But with the spl calls being replaced with > > noops, and as far as I can tell the driver is not using mutex, there > > doesn't appear to be any locking. So the driver can step on itself. > > > Well, there is locking around a couple of mutex's via FW_GLOCK(). Ah, I wasn't grepping for the right string. So there *is* mutex locking. Although the lingering spl calls are still troubling. From bugmaster at FreeBSD.org Mon Dec 29 03:06:54 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Dec 29 03:07:46 2008 Subject: Current problem reports assigned to freebsd-firewire@FreeBSD.org Message-ID: <200812291106.mBTB6rmZ024416@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/113785 firewire [firewire] dropouts when playing DV on firewire o kern/74238 firewire [firewire] fw_rcv: unknown response; firewire ad-hoc w 2 problems total.