Re: kern/112119: system hangs when starts k3b on RELENG_6
On Tue, 2007-05-01 at 13:52 +0100, Chris Rees wrote: > If it's committed on HEAD, doesn't that mean it's only on 7-CURRENT? When > does this fix get through to 6-STABLE, if you know, please? Or am I being > ignorant? > > Thanks > Chris > Don't top-post please, very difficult to follow. In the commit message, it will state when it should be MFC'ed (Merged From Current). In this case: On Mon, 2007-04-30 at 09:26 +, Thomas Quinot wrote: > thomas 2007-04-30 09:26:43 UTC > > FreeBSD src repository > > Modified files: > sys/dev/ata atapi-cam.c > Log: > (atapi_cb): Fix test for the presence of sense data. An incorrect > condition > was being tested, which would result in a system hang in some > configurations. > > PR: kern/112119 > Reviewed by: scottl > MFC after: 3 days > > Revision Changes Path > 1.52 +2 -2 src/sys/dev/ata/atapi-cam.c signature.asc Description: This is a digitally signed message part
Re: kern/112119: system hangs when starts k3b on RELENG_6
If it's committed on HEAD, doesn't that mean it's only on 7-CURRENT? When does this fix get through to 6-STABLE, if you know, please? Or am I being ignorant? Thanks Chris Message: 2 Date: Mon, 30 Apr 2007 11:27:27 +0200 From: Thomas Quinot <[EMAIL PROTECTED]> Subject: Re: kern/112119: system hangs when starts k3b on RELENG_6 To: Ganbold <[EMAIL PROTECTED]> Cc: freebsd-stable@FreeBSD.ORG, [EMAIL PROTECTED], [EMAIL PROTECTED],Nikolay Pavlov <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=us-ascii * Ganbold, 2007-04-30 : > Scott, Thomas, thank you very much for the effort fixing this problem. > k3b starts fine with this patch. Thanks for your feedback. The fix has been committed on HEAD. Thomas. -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" End of freebsd-stable Digest, Vol 204, Issue 1 ** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/112119: system hangs when starts k3b on RELENG_6
* Ganbold, 2007-04-30 : > Scott, Thomas, thank you very much for the effort fixing this problem. > k3b starts fine with this patch. Thanks for your feedback. The fix has been committed on HEAD. Thomas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/112119: system hangs when starts k3b on RELENG_6
Thomas Quinot wrote: * Scott Long, 2007-04-27 : Oh hell, I know exactly what the problem is! The opcode for a TEST_UNIT_READY is 0x00. This is probably the command that is generating the CHECK_CONDITION. The test for saved_cmd is entirely bogus. H. Looks like a very plausible culprit. Good catch Scott! (I felt there had to be something wrong when I wrote that test, incidentally, precisely because of TEST_UNIT_READY). Nikolay, Ganbold, (and others), here's another patch against 1.42.2.3, please let me know if it works for you. Thomas. Index: atapi-cam.c === RCS file: /space/mirror/ncvs/src/sys/dev/ata/atapi-cam.c,v retrieving revision 1.50 diff -u -r1.50 atapi-cam.c --- atapi-cam.c 14 Mar 2007 01:59:00 - 1.50 +++ atapi-cam.c 27 Apr 2007 19:26:09 - @@ -729,7 +743,7 @@ * issued a REQUEST SENSE automatically and that operation * returned without error. */ - if (request->u.atapi.saved_cmd != 0 && request->error == 0) { + if (request->u.atapi.sense.key != 0 && request->error == 0) { bcopy (&request->u.atapi.sense, &csio->sense_data, sizeof(struct atapi_sense)); csio->ccb_h.status |= CAM_AUTOSNS_VALID; } Scott, Thomas, thank you very much for the effort fixing this problem. k3b starts fine with this patch. Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/112119: system hangs when starts k3b on RELENG_6
On Fri, 27 Apr 2007 14:28:14 -0600 Scott Long <[EMAIL PROTECTED]> wrote: > Thomas Quinot wrote: > > * Scott Long, 2007-04-27 : > > > >> Oh hell, I know exactly what the problem is! The opcode for a > >> TEST_UNIT_READY is 0x00. This is probably the command that is > >> generating the CHECK_CONDITION. The test for saved_cmd is entirely > >> bogus. > > > > H. Looks like a very plausible culprit. Good catch Scott! > > (I felt there had to be something wrong when I wrote that test, > > incidentally, precisely because of TEST_UNIT_READY). > > > > Nikolay, Ganbold, (and others), here's another patch against > > 1.42.2.3, please let me know if it works for you. > > > > Thomas. > > > > Index: atapi-cam.c > > === > > RCS file: /space/mirror/ncvs/src/sys/dev/ata/atapi-cam.c,v > > retrieving revision 1.50 > > diff -u -r1.50 atapi-cam.c > > --- atapi-cam.c 14 Mar 2007 01:59:00 - 1.50 > > +++ atapi-cam.c 27 Apr 2007 19:26:09 - > > @@ -729,7 +743,7 @@ > > * issued a REQUEST SENSE automatically and that > > operation > > * returned without error. > > */ > > - if (request->u.atapi.saved_cmd != 0 && > > request->error == 0) { > > + if (request->u.atapi.sense.key != 0 && > > request->error == 0) { bcopy (&request->u.atapi.sense, > > &csio->sense_data, sizeof(struct atapi_sense)); csio->ccb_h.status > > |= CAM_AUTOSNS_VALID; } > > Right, just make sure that this isn't filled with garbage before you > send the command. If you're using ata_alloc_request(), and you're not > recycling requests internally, then you should be fine. > > Scott > I just installed this patch on my i386 system and I can now start K3B without the system crashing. I still have this in dmesg when starting the system: acd1: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 And this in /var/log/messages each time I start K3B Apr 27 10:47:39 p4 kernel: acd1: FAILURE - MODE_SENSE_BIG ILLEGAL REQUEST asc=0x24 ascq=0x00 Apr 27 10:47:39 p4 last message repeated 3 times Apr 27 10:52:07 p4 kernel: acd1: FAILURE - MODE_SENSE_BIG ILLEGAL REQUEST asc=0x24 ascq=0x00 I successfully burned an audio CD even with the above errors. The patch seems to work. I will try it on my amd64 machine and report if it does not work there. Thank you Robert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/112119: system hangs when starts k3b on RELENG_6
Thomas Quinot wrote: * Scott Long, 2007-04-27 : Oh hell, I know exactly what the problem is! The opcode for a TEST_UNIT_READY is 0x00. This is probably the command that is generating the CHECK_CONDITION. The test for saved_cmd is entirely bogus. H. Looks like a very plausible culprit. Good catch Scott! (I felt there had to be something wrong when I wrote that test, incidentally, precisely because of TEST_UNIT_READY). Nikolay, Ganbold, (and others), here's another patch against 1.42.2.3, please let me know if it works for you. Thomas. Index: atapi-cam.c === RCS file: /space/mirror/ncvs/src/sys/dev/ata/atapi-cam.c,v retrieving revision 1.50 diff -u -r1.50 atapi-cam.c --- atapi-cam.c 14 Mar 2007 01:59:00 - 1.50 +++ atapi-cam.c 27 Apr 2007 19:26:09 - @@ -729,7 +743,7 @@ * issued a REQUEST SENSE automatically and that operation * returned without error. */ - if (request->u.atapi.saved_cmd != 0 && request->error == 0) { + if (request->u.atapi.sense.key != 0 && request->error == 0) { bcopy (&request->u.atapi.sense, &csio->sense_data, sizeof(struct atapi_sense)); csio->ccb_h.status |= CAM_AUTOSNS_VALID; } Right, just make sure that this isn't filled with garbage before you send the command. If you're using ata_alloc_request(), and you're not recycling requests internally, then you should be fine. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/112119: system hangs when starts k3b on RELENG_6
* Scott Long, 2007-04-27 : > Oh hell, I know exactly what the problem is! The opcode for a > TEST_UNIT_READY is 0x00. This is probably the command that is > generating the CHECK_CONDITION. The test for saved_cmd is entirely > bogus. H. Looks like a very plausible culprit. Good catch Scott! (I felt there had to be something wrong when I wrote that test, incidentally, precisely because of TEST_UNIT_READY). Nikolay, Ganbold, (and others), here's another patch against 1.42.2.3, please let me know if it works for you. Thomas. Index: atapi-cam.c === RCS file: /space/mirror/ncvs/src/sys/dev/ata/atapi-cam.c,v retrieving revision 1.50 diff -u -r1.50 atapi-cam.c --- atapi-cam.c 14 Mar 2007 01:59:00 - 1.50 +++ atapi-cam.c 27 Apr 2007 19:26:09 - @@ -729,7 +743,7 @@ * issued a REQUEST SENSE automatically and that operation * returned without error. */ - if (request->u.atapi.saved_cmd != 0 && request->error == 0) { + if (request->u.atapi.sense.key != 0 && request->error == 0) { bcopy (&request->u.atapi.sense, &csio->sense_data, sizeof(struct atapi_sense)); csio->ccb_h.status |= CAM_AUTOSNS_VALID; } ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/112119: system hangs when starts k3b on RELENG_6
Nikolay Pavlov wrote: On Friday, 27 April 2007 at 17:32:18 +0200, Thomas Quinot wrote: * Ganbold.TS, 2007-04-27 : I tried your patch at http://www.freebsd.org/cgi/query-pr.cgi?pr=103602&getpatch=12 and the problem is still the same. Ssytem freezes upon start of k3b. I also tried your attached patch, which reverts part of rev. 1.42.2.3 and the problem is still the same, system hangs when starts k3b. Thanks, that's useful info. Please try the attached patch instead, which reverts another part of 1.42.2.3 (I'm trying to figure out exactly *which* part of this change is causing the problem). Also, were you able to capture system console output at the point where the crash occurs? We might have some indications there. This patch works for me. I do not have a reboot and i am able to succesfully burn a cd. Thomas. Index: atapi-cam.c === RCS file: /space/mirror/ncvs/src/sys/dev/ata/atapi-cam.c,v retrieving revision 1.42.2.3 retrieving revision 1.42.2.2 diff -u -r1.42.2.3 -r1.42.2.2 --- atapi-cam.c 29 Mar 2007 20:08:32 - 1.42.2.3 +++ atapi-cam.c 6 Mar 2007 16:56:50 - 1.42.2.2 @@ -697,39 +680,32 @@ csio->ccb_h.status |= CAM_AUTOSNS_VALID; } } else if (request->result != 0) { - if ((request->flags & ATA_R_TIMEOUT) != 0) { - rc = CAM_CMD_TIMEOUT; - } else { - rc = CAM_SCSI_STATUS_ERROR; - csio->scsi_status = SCSI_STATUS_CHECK_COND; + rc = CAM_SCSI_STATUS_ERROR; + csio->scsi_status = SCSI_STATUS_CHECK_COND; - if ((csio->ccb_h.flags & CAM_DIS_AUTOSENSE) == 0) { + if ((csio->ccb_h.flags & CAM_DIS_AUTOSENSE) == 0) { #if 0 - static const int8_t ccb[16] = { ATAPI_REQUEST_SENSE, 0, 0, 0, - sizeof(struct atapi_sense), 0, 0, 0, 0, 0, 0, - 0, 0, 0, 0, 0 }; - - bcopy (ccb, request->u.atapi.ccb, sizeof ccb); - request->data = (caddr_t)&csio->sense_data; - request->bytecount = sizeof(struct atapi_sense); - request->transfersize = min(request->bytecount, 65534); - request->timeout = csio->ccb_h.timeout / 1000; - request->retries = 2; - request->flags = ATA_R_QUIET|ATA_R_ATAPI|ATA_R_IMMEDIATE; - hcb->flags |= AUTOSENSE; + static const int8_t ccb[16] = { ATAPI_REQUEST_SENSE, 0, 0, 0, + sizeof(struct atapi_sense), 0, 0, 0, 0, 0, 0, + 0, 0, 0, 0, 0 }; + + bcopy (ccb, request->u.atapi.ccb, sizeof ccb); + request->data = (caddr_t)&csio->sense_data; + request->bytecount = sizeof(struct atapi_sense); + request->transfersize = min(request->bytecount, 65534); + request->timeout = csio->ccb_h.timeout / 1000; + request->retries = 2; + request->flags = ATA_R_QUIET|ATA_R_ATAPI|ATA_R_IMMEDIATE; + hcb->flags |= AUTOSENSE; - ata_queue_request(request); - return; + ata_queue_request(request); + return; #else - /* -* Use auto-sense data from the ATA layer, if it has -* issued a REQUEST SENSE automatically and that operation -* returned without error. -*/ - if (request->u.atapi.saved_cmd != 0 && request->error == 0) { - bcopy (&request->u.atapi.sense, &csio->sense_data, sizeof(struct atapi_sense)); - csio->ccb_h.status |= CAM_AUTOSNS_VALID; - } + /* The ATA driver has already requested sense for us. */ + if (request->error == 0) { + /* The ATA autosense suceeded. */ + bcopy (&request->u.atapi.sense, &csio->sense_data, sizeof(struct atapi_sense)); + csio->ccb_h.status |= CAM_AUTOSNS_VALID; } #endif } My best guess is that request->u.atapi.saved_cmd isn't getting preserved when ata_completed() does an automatic REQUEST_SENSE. Not sure if this is true or why it would happen. But if that's the case, then CAM is going to manually request sense, which atapi-cam and ata will likely treat as a normal DMA capable command. Note that the autosense code in the ATA driver disables DMA for the REQUEST_SENSE command. This might be a key issue; the drive might be getting very unhappy with a DMA flagged REQUEST_SENSE command, especially if it's already in a CHECK_CONDITION state. This unhappiness might be leading to the interrupt storm and observed deadlock on UP system. With the patch above, sense info is reported to CAM regardless of the contents of saved_cmd, preventing CAM from generating the troublesome REQUEST_SENSE on its own. Oh hell, I know exactly what the problem is! The opcode for a TEST_UNIT_READY is 0x00. This is probably the command that is generating the CHECK_CONDITION. The test for saved_cmd is entirely bogus. W
Re: kern/112119: system hangs when starts k3b on RELENG_6
On Friday, 27 April 2007 at 17:32:18 +0200, Thomas Quinot wrote: > * Ganbold.TS, 2007-04-27 : > > > I tried your patch at > > http://www.freebsd.org/cgi/query-pr.cgi?pr=103602&getpatch=12 and the > > problem is still the same. Ssytem freezes upon start of k3b. > > > > I also tried your attached patch, which reverts part of rev. 1.42.2.3 > > and the problem is still the same, system hangs when starts k3b. > > Thanks, that's useful info. Please try the attached patch instead, which > reverts another part of 1.42.2.3 (I'm trying to figure out exactly > *which* part of this change is causing the problem). > > Also, were you able to capture system console output at the point where > the crash occurs? We might have some indications there. This patch works for me. I do not have a reboot and i am able to succesfully burn a cd. > > Thomas. > > Index: atapi-cam.c > === > RCS file: /space/mirror/ncvs/src/sys/dev/ata/atapi-cam.c,v > retrieving revision 1.42.2.3 > retrieving revision 1.42.2.2 > diff -u -r1.42.2.3 -r1.42.2.2 > --- atapi-cam.c 29 Mar 2007 20:08:32 - 1.42.2.3 > +++ atapi-cam.c 6 Mar 2007 16:56:50 - 1.42.2.2 > @@ -697,39 +680,32 @@ > csio->ccb_h.status |= CAM_AUTOSNS_VALID; > } > } else if (request->result != 0) { > - if ((request->flags & ATA_R_TIMEOUT) != 0) { > - rc = CAM_CMD_TIMEOUT; > - } else { > - rc = CAM_SCSI_STATUS_ERROR; > - csio->scsi_status = SCSI_STATUS_CHECK_COND; > + rc = CAM_SCSI_STATUS_ERROR; > + csio->scsi_status = SCSI_STATUS_CHECK_COND; > > - if ((csio->ccb_h.flags & CAM_DIS_AUTOSENSE) == 0) { > + if ((csio->ccb_h.flags & CAM_DIS_AUTOSENSE) == 0) { > #if 0 > - static const int8_t ccb[16] = { ATAPI_REQUEST_SENSE, 0, 0, 0, > - sizeof(struct atapi_sense), 0, 0, 0, 0, 0, 0, > - 0, 0, 0, 0, 0 }; > - > - bcopy (ccb, request->u.atapi.ccb, sizeof ccb); > - request->data = (caddr_t)&csio->sense_data; > - request->bytecount = sizeof(struct atapi_sense); > - request->transfersize = min(request->bytecount, 65534); > - request->timeout = csio->ccb_h.timeout / 1000; > - request->retries = 2; > - request->flags = ATA_R_QUIET|ATA_R_ATAPI|ATA_R_IMMEDIATE; > - hcb->flags |= AUTOSENSE; > + static const int8_t ccb[16] = { ATAPI_REQUEST_SENSE, 0, 0, 0, > + sizeof(struct atapi_sense), 0, 0, 0, 0, 0, 0, > + 0, 0, 0, 0, 0 }; > + > + bcopy (ccb, request->u.atapi.ccb, sizeof ccb); > + request->data = (caddr_t)&csio->sense_data; > + request->bytecount = sizeof(struct atapi_sense); > + request->transfersize = min(request->bytecount, 65534); > + request->timeout = csio->ccb_h.timeout / 1000; > + request->retries = 2; > + request->flags = ATA_R_QUIET|ATA_R_ATAPI|ATA_R_IMMEDIATE; > + hcb->flags |= AUTOSENSE; > > - ata_queue_request(request); > - return; > + ata_queue_request(request); > + return; > #else > - /* > - * Use auto-sense data from the ATA layer, if it has > - * issued a REQUEST SENSE automatically and that operation > - * returned without error. > - */ > - if (request->u.atapi.saved_cmd != 0 && request->error == 0) { > - bcopy (&request->u.atapi.sense, &csio->sense_data, > sizeof(struct atapi_sense)); > - csio->ccb_h.status |= CAM_AUTOSNS_VALID; > - } > + /* The ATA driver has already requested sense for us. */ > + if (request->error == 0) { > + /* The ATA autosense suceeded. */ > + bcopy (&request->u.atapi.sense, &csio->sense_data, > sizeof(struct atapi_sense)); > + csio->ccb_h.status |= CAM_AUTOSNS_VALID; > } > #endif > } > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- == - Best regards, Nikolay Pavlov. <<<--- == ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/112119: system hangs when starts k3b on RELENG_6
* Ganbold.TS, 2007-04-27 : > I tried your patch at > http://www.freebsd.org/cgi/query-pr.cgi?pr=103602&getpatch=12 and the > problem is still the same. Ssytem freezes upon start of k3b. > > I also tried your attached patch, which reverts part of rev. 1.42.2.3 > and the problem is still the same, system hangs when starts k3b. Thanks, that's useful info. Please try the attached patch instead, which reverts another part of 1.42.2.3 (I'm trying to figure out exactly *which* part of this change is causing the problem). Also, were you able to capture system console output at the point where the crash occurs? We might have some indications there. Thomas. Index: atapi-cam.c === RCS file: /space/mirror/ncvs/src/sys/dev/ata/atapi-cam.c,v retrieving revision 1.42.2.3 retrieving revision 1.42.2.2 diff -u -r1.42.2.3 -r1.42.2.2 --- atapi-cam.c 29 Mar 2007 20:08:32 - 1.42.2.3 +++ atapi-cam.c 6 Mar 2007 16:56:50 - 1.42.2.2 @@ -697,39 +680,32 @@ csio->ccb_h.status |= CAM_AUTOSNS_VALID; } } else if (request->result != 0) { - if ((request->flags & ATA_R_TIMEOUT) != 0) { - rc = CAM_CMD_TIMEOUT; - } else { - rc = CAM_SCSI_STATUS_ERROR; - csio->scsi_status = SCSI_STATUS_CHECK_COND; + rc = CAM_SCSI_STATUS_ERROR; + csio->scsi_status = SCSI_STATUS_CHECK_COND; - if ((csio->ccb_h.flags & CAM_DIS_AUTOSENSE) == 0) { + if ((csio->ccb_h.flags & CAM_DIS_AUTOSENSE) == 0) { #if 0 - static const int8_t ccb[16] = { ATAPI_REQUEST_SENSE, 0, 0, 0, - sizeof(struct atapi_sense), 0, 0, 0, 0, 0, 0, - 0, 0, 0, 0, 0 }; - - bcopy (ccb, request->u.atapi.ccb, sizeof ccb); - request->data = (caddr_t)&csio->sense_data; - request->bytecount = sizeof(struct atapi_sense); - request->transfersize = min(request->bytecount, 65534); - request->timeout = csio->ccb_h.timeout / 1000; - request->retries = 2; - request->flags = ATA_R_QUIET|ATA_R_ATAPI|ATA_R_IMMEDIATE; - hcb->flags |= AUTOSENSE; + static const int8_t ccb[16] = { ATAPI_REQUEST_SENSE, 0, 0, 0, + sizeof(struct atapi_sense), 0, 0, 0, 0, 0, 0, + 0, 0, 0, 0, 0 }; + + bcopy (ccb, request->u.atapi.ccb, sizeof ccb); + request->data = (caddr_t)&csio->sense_data; + request->bytecount = sizeof(struct atapi_sense); + request->transfersize = min(request->bytecount, 65534); + request->timeout = csio->ccb_h.timeout / 1000; + request->retries = 2; + request->flags = ATA_R_QUIET|ATA_R_ATAPI|ATA_R_IMMEDIATE; + hcb->flags |= AUTOSENSE; - ata_queue_request(request); - return; + ata_queue_request(request); + return; #else - /* -* Use auto-sense data from the ATA layer, if it has -* issued a REQUEST SENSE automatically and that operation -* returned without error. -*/ - if (request->u.atapi.saved_cmd != 0 && request->error == 0) { - bcopy (&request->u.atapi.sense, &csio->sense_data, sizeof(struct atapi_sense)); - csio->ccb_h.status |= CAM_AUTOSNS_VALID; - } + /* The ATA driver has already requested sense for us. */ + if (request->error == 0) { + /* The ATA autosense suceeded. */ + bcopy (&request->u.atapi.sense, &csio->sense_data, sizeof(struct atapi_sense)); + csio->ccb_h.status |= CAM_AUTOSNS_VALID; } #endif } ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/112119: system hangs when starts k3b on RELENG_6
On Friday, 27 April 2007 at 9:40:19 +0800, Ganbold wrote: > Thomas Quinot wrote: > >* Ganbold, 2007-04-25 : > > > > > >>>Description: > >>> > >>With atapi-cam.c (rev 1.42.2.3) when running k3b application, system > >>completely hangs on k3b splash screen and I had to use power button only > >>to restart the machine. > >> > > > >Extremely strange. I can't offer any definite solution at this point, > >since I have no idea how this change could cause a system to hang. Here > >are a few possible investigation ideas: > > > >* AFAIK k3b is just a front-end for command-line tools. You should > > determine what exact commands are spawned by k3b to identify which of > > these is causing the apparent hang; > > > >* it would also be useful to enable CAM debugging options (see > > "man 4 cam", option CAMDEBUG, and flags CAM_DEBUG_TRACE and > > CAM_DEBUG_SUBTRACE) and to capture all console output up to the hang > > (for example using a serial console) > > > >* if Scott's hunch of an interrupt storm is correct, then this issue > > might be related to the DMA problem described under PR 103602, so > > it would be useful to try the last patch I sent on that PR: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=103602&getpatch=12 > > > >* if all else fails, please let me know if the attached patch, which > > reverts part of rev. 1.42.2.3, changes anything. I've tried your patch on recent current with all CAM options, but no luck. I am still having a reboot on my notebook while trying to run k3b. No errors... no panic... just a reboot. > > > > I tried your attached patch and the problem is still the same. System hangs > when starts k3b. > With atapi-cam.c rev. 1.42.2.2, k3b starts fine, system doesn't hang. > > For your information I have k3b normal startup messages with atapi-cam.c rev. > 1.42.2.2. > It might help to find the problem. > > devil# k3b > Only one line in dcopserver file !: > DCOPClient::attachInternal. Attach failed networkIdsList argument is NULL > Only one line in dcopserver file !: > DCOPClient::attachInternal. Attach failed networkIdsList argument is NULL > kbuildsycoca running... > devil# kdecore (KAction): WARNING: KActionCollection::KActionCollection( > QObject *parent, const char *name, KInstance *instance ) > k3b: (K3bCdrecordProgram) could not start /opt/schily/bin > k3b: (K3bMkisofsProgram) could not start /opt/schily/bin > k3b: (K3bCdrecordProgram) could not start /root/bin > k3b: (K3bMkisofsProgram) could not start /root/bin > k3b: (K3bExternalBinManager) Cdrecord 2.1 features: gracetime, overburn, > cdtext, clone, tao, cuefile, xamix, plain-atapi, hacked-atapi, audio-stdin, > burnfree > k3b: (K3bExternalBinManager) 2 1 -1 seems to be cdrecord version >= 1.11a02, > using burnfree instead of burnproof > k3b: (K3bExternalBinManager) seems to be cdrecord version >= 1.11a31, support > for Just Link via burnfree driveroption > (BSDDeviceScan) number of matches 10 > (BSDDeviceScan) add device /dev/cd0:1:0:0 > (K3bDevice::Device) /dev/cd0: init() > (K3bDevice::openDevice) open device /dev/pass0 succeeded. > (K3bDevice::openDevice) open device /dev/pass0 succeeded. > (K3bDevice::ScsiCommand) transport command 12, length: 6 > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::Device) /dev/cd0 feature: CD Mastering > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::Device) /dev/cd0 feature: CD Track At Once > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::Device) /dev/cd0 feature: CD-RW Media Write Support > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::Device) /dev/cd0 feature: DVD Read (MMC5) > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::Device) /dev/cd0 feature: DVD+R > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::Device) /dev/cd0 feature: DVD+RW > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::Device) /dev/cd0 feature: DVD+R Double Layer > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::Device) /dev/cd0 feature: DVD-R/-RW Write > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::Device) /dev/cd0 feature: Rigid Restricted Overwrite > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::ScsiCommand) transport command 46, length: 10 > (K3bDevice::openDevice) open device /dev/pass0 succeeded. > (K3bDevice::openDevice) open device /dev/pass0 succeeded. > (K3bDevice::ScsiCommand) transport command 5a, length: 10 > (K3bDevice::ScsiCommand) transport command 5a, length: 10 > (K3bDevice::D
Re: kern/112119: system hangs when starts k3b on RELENG_6
Thomas, I tried your patch at http://www.freebsd.org/cgi/query-pr.cgi?pr=103602&getpatch=12 and the problem is still the same. Ssytem freezes upon start of k3b. I also tried your attached patch, which reverts part of rev. 1.42.2.3 and the problem is still the same, system hangs when starts k3b. Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/112119: system hangs when starts k3b on RELENG_6
Thomas Quinot wrote: * Ganbold, 2007-04-25 : Description: With atapi-cam.c (rev 1.42.2.3) when running k3b application, system completely hangs on k3b splash screen and I had to use power button only to restart the machine. Extremely strange. I can't offer any definite solution at this point, since I have no idea how this change could cause a system to hang. Here are a few possible investigation ideas: * AFAIK k3b is just a front-end for command-line tools. You should determine what exact commands are spawned by k3b to identify which of these is causing the apparent hang; * it would also be useful to enable CAM debugging options (see "man 4 cam", option CAMDEBUG, and flags CAM_DEBUG_TRACE and CAM_DEBUG_SUBTRACE) and to capture all console output up to the hang (for example using a serial console) * if Scott's hunch of an interrupt storm is correct, then this issue might be related to the DMA problem described under PR 103602, so it would be useful to try the last patch I sent on that PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=103602&getpatch=12 * if all else fails, please let me know if the attached patch, which reverts part of rev. 1.42.2.3, changes anything. I will try http://www.freebsd.org/cgi/query-pr.cgi?pr=103602&getpatch=12 patch later today and let you know. thanks, Ganbold Thomas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/112119: system hangs when starts k3b on RELENG_6
Thomas Quinot wrote: * Ganbold, 2007-04-25 : Description: With atapi-cam.c (rev 1.42.2.3) when running k3b application, system completely hangs on k3b splash screen and I had to use power button only to restart the machine. Extremely strange. I can't offer any definite solution at this point, since I have no idea how this change could cause a system to hang. Here are a few possible investigation ideas: * AFAIK k3b is just a front-end for command-line tools. You should determine what exact commands are spawned by k3b to identify which of these is causing the apparent hang; * it would also be useful to enable CAM debugging options (see "man 4 cam", option CAMDEBUG, and flags CAM_DEBUG_TRACE and CAM_DEBUG_SUBTRACE) and to capture all console output up to the hang (for example using a serial console) * if Scott's hunch of an interrupt storm is correct, then this issue might be related to the DMA problem described under PR 103602, so it would be useful to try the last patch I sent on that PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=103602&getpatch=12 * if all else fails, please let me know if the attached patch, which reverts part of rev. 1.42.2.3, changes anything. I tried your attached patch and the problem is still the same. System hangs when starts k3b. With atapi-cam.c rev. 1.42.2.2, k3b starts fine, system doesn't hang. For your information I have k3b normal startup messages with atapi-cam.c rev. 1.42.2.2. It might help to find the problem. devil# k3b Only one line in dcopserver file !: DCOPClient::attachInternal. Attach failed networkIdsList argument is NULL Only one line in dcopserver file !: DCOPClient::attachInternal. Attach failed networkIdsList argument is NULL kbuildsycoca running... devil# kdecore (KAction): WARNING: KActionCollection::KActionCollection( QObject *parent, const char *name, KInstance *instance ) k3b: (K3bCdrecordProgram) could not start /opt/schily/bin k3b: (K3bMkisofsProgram) could not start /opt/schily/bin k3b: (K3bCdrecordProgram) could not start /root/bin k3b: (K3bMkisofsProgram) could not start /root/bin k3b: (K3bExternalBinManager) Cdrecord 2.1 features: gracetime, overburn, cdtext, clone, tao, cuefile, xamix, plain-atapi, hacked-atapi, audio-stdin, burnfree k3b: (K3bExternalBinManager) 2 1 -1 seems to be cdrecord version >= 1.11a02, using burnfree instead of burnproof k3b: (K3bExternalBinManager) seems to be cdrecord version >= 1.11a31, support for Just Link via burnfree driveroption (BSDDeviceScan) number of matches 10 (BSDDeviceScan) add device /dev/cd0:1:0:0 (K3bDevice::Device) /dev/cd0: init() (K3bDevice::openDevice) open device /dev/pass0 succeeded. (K3bDevice::openDevice) open device /dev/pass0 succeeded. (K3bDevice::ScsiCommand) transport command 12, length: 6 (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: CD Mastering (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: CD Track At Once (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: CD-RW Media Write Support (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: DVD Read (MMC5) (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: DVD+R (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: DVD+RW (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: DVD+R Double Layer (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: DVD-R/-RW Write (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: Rigid Restricted Overwrite (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::openDevice) open device /dev/pass0 succeeded. (K3bDevice::openDevice) open device /dev/pass0 succeeded. (K3bDevice::ScsiCommand) transport command 5a, length: 10 (K3bDevice::ScsiCommand) transport command 5a, length: 10 (K3bDevice::Device) /dev/cd0: dataLen: 60 (K3bDevice::Device) /dev/cd0: checking for TAO (K3bDevice::ScsiCommand) transport command 55, length: 10 (K3bDevice::Device) /dev/cd0: checking for SAO (K3bDevice::ScsiCommand) transport command 55, length: 10 (K3bDevice::Device) /dev/cd0: checking for SAO_R96P (K3bDevice::ScsiCommand) transport command 55, length: 10 (K3bDevice::Device) /dev/cd0: checking for SAO_R96R (K3bDevice::ScsiCommand) transport command 55, length: 10 (K3bDev