From owner-freebsd-scsi@FreeBSD.ORG Sun Jan 14 09:53:40 2007 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 337D916A412; Sun, 14 Jan 2007 09:53:40 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id DBC6E13C45D; Sun, 14 Jan 2007 09:53:39 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1H623V-0008yq-Dl; Sun, 14 Jan 2007 11:53:37 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Scott Long In-reply-to: <45A91A02.906@samsco.org> References: <20070112195549.GA77181@freebie.xs4all.nl> <45A7F6A4.4030707@samsco.org> <45A91A02.906@samsco.org> Comments: In-reply-to Scott Long message dated "Sat, 13 Jan 2007 10:42:26 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Jan 2007 11:53:37 +0200 From: Danny Braniss Message-ID: Cc: Wilko Bulte , Pawel Jakub Dawidek , freebsd-hackers@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: iSCSI disconnects dilema X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2007 09:53:40 -0000 ... > > So you had a scenario where a program was doing I/O right up to system > (initiator) shutdown, and some of those I/O's got lost in the process? > I guess I don't understand why the OS didn't flush all outstanding I/O > buffers after terminating the program and before finishing the shutdown. > Maybe you are doing something illegal in your driver, or maybe you need > to implement a kernel shutdown hook that will allow you to block the > shutdown until everything is flushed. > the problem was solved! it just took me a while to find the cause :-) the driver picks the fd/socket from userland, via fgetsock(...), this increases the socket usage count, which I wrongly believed would save me from the userland exiting. a call to fget(...) now solves this, and so shutdown can now flush all iscsi buffers, and fsck'in is not necesary on reboot. danny > Scott From owner-freebsd-scsi@FreeBSD.ORG Mon Jan 15 11:08:28 2007 Return-Path: X-Original-To: freebsd-scsi@FreeBSD.org Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0066516A5FF for ; Mon, 15 Jan 2007 11:08:27 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id E50CF13C4C8 for ; Mon, 15 Jan 2007 11:08:27 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l0FB8Phb031833 for ; Mon, 15 Jan 2007 11:08:25 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l0FB8OU1031829 for freebsd-scsi@FreeBSD.org; Mon, 15 Jan 2007 11:08:24 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 15 Jan 2007 11:08:24 GMT Message-Id: <200701151108.l0FB8OU1031829@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-scsi@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 11:08:28 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/27059 scsi [sym] SCSI subsystem hangs under heavy load on (Server o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/40895 scsi wierd kernel / device driver bug o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/60598 scsi wire down of scsi devices conflicts with config o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 o kern/81887 scsi [aac] Adaptec SCSI 2130S aac0: GetDeviceProbeInfo comm o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/93128 scsi [sym] FreeBSD 6.1 BETA 1 has problems with Symbios/LSI o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/99954 scsi [ahc] reading from DVD failes on 6.x (regression) 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/23314 scsi aic driver fails to detect Adaptec 1520B unless PnP is o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce o kern/38828 scsi [feature request] DPT PM2012B/90 doesn't work o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/96133 scsi [scsi] [patch] add scsi quirk for joyfly 128mb flash u o kern/103702 scsi [cam] [patch] ChipsBnk: Unsupported USB memory stick 7 problems total. From owner-freebsd-scsi@FreeBSD.ORG Mon Jan 15 17:12:00 2007 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3BA716A52E for ; Mon, 15 Jan 2007 17:12:00 +0000 (UTC) (envelope-from weiss@uni-mainz.de) Received: from mailgate02.zdv.uni-mainz.de (mailgate02.zdv.Uni-Mainz.DE [134.93.178.132]) by mx1.freebsd.org (Postfix) with ESMTP id 47FAE13C45E for ; Mon, 15 Jan 2007 17:12:00 +0000 (UTC) (envelope-from weiss@uni-mainz.de) Received: from exfront01.zdv.uni-mainz.de ([134.93.176.49]) by mailgate02.zdv.uni-mainz.de with ESMTP; 15 Jan 2007 17:42:10 +0100 Received: from EXCHANGE01.zdv.Uni-Mainz.DE ([134.93.177.33]) by exfront01.zdv.Uni-Mainz.DE with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 17:42:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jan 2007 17:42:09 +0100 Message-ID: <4A2AB4CC01998D46807D8032B06CDBDA02F91407@EXCHANGE01.zdv.Uni-Mainz.DE> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: iSCSI disconnects dilema Thread-Index: Acc4xBlUMFI4Zt5fQAaXWAwgWuAHeg== From: "Weiss, Juergen" To: X-OriginalArrivalTime: 15 Jan 2007 16:42:09.0879 (UTC) FILETIME=[19ABE670:01C738C4] Subject: Re: iSCSI disconnects dilema X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 17:12:00 -0000 I have been testing iscsi-17.5 with an infortrend iscsi raid.=20 If easily achievable, the timeout for devices in use should be long enough for network switch reboot and/or ISCSI target reboot (> 5 min). The loss of a device in use (mounted as an ufs file system) usually requires the machine to be rebooted (which I do not blame the iscsi driver for). As someone else already explained, ufs is not designed for that. So I would rather=20 have the initiator try forever, until an administrator either fixes the network or target problem or manually=20 terminates the connection (would be similar to nfs hard mounts=20 with intr option). Regards Juergen Weiss Juergen Weiss | Universitaet Mainz, Zentrum fuer Datenverarbeitung, weiss@uni-mainz.de| 55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-26407 From owner-freebsd-scsi@FreeBSD.ORG Tue Jan 16 16:36:23 2007 Return-Path: X-Original-To: scsi@freebsd.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0CCF16A407 for ; Tue, 16 Jan 2007 16:36:23 +0000 (UTC) (envelope-from lee.jenkins@hp.com) Received: from ccerelbas04.cce.hp.com (ccerelbas04.cce.hp.com [161.114.21.107]) by mx1.freebsd.org (Postfix) with ESMTP id C3E3A13C428 for ; Tue, 16 Jan 2007 16:36:23 +0000 (UTC) (envelope-from lee.jenkins@hp.com) Received: from G3W0060.americas.hpqcorp.net (g3w0060.americas.hpqcorp.net [16.232.1.19]) by ccerelbas04.cce.hp.com (Postfix) with ESMTP id C135F347E6 for ; Tue, 16 Jan 2007 10:12:12 -0600 (CST) Received: from G3W0633.americas.hpqcorp.net ([16.233.58.103]) by G3W0060.americas.hpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 10:12:12 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jan 2007 16:12:08 -0000 Message-ID: <691AAA721A6B4D449DC0F8760E5555B80F4F95@G3W0633.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ciss driver for HP Smart Array thread-index: Acc5iRIdllkniQrNSSC8rNoXdNi2jA== From: "Jenkins, Lee" To: X-OriginalArrivalTime: 16 Jan 2007 16:12:12.0163 (UTC) FILETIME=[148FF530:01C73989] Cc: Subject: ciss driver for HP Smart Array X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 16:36:24 -0000 Can someone please direct me to who supports the FreeBSD ciss driver for HP Smart Array controller products? This may seem an odd question coming from an HP employee, but I haven't been able to find our internal FreeBSD support. I'm not a list subscriber, so please reply directly or CC: me in your response. Thanks, Lee Jenkins HP Storage Performance From owner-freebsd-scsi@FreeBSD.ORG Thu Jan 18 02:29:08 2007 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9380E16A40F for ; Thu, 18 Jan 2007 02:29:08 +0000 (UTC) (envelope-from rodrigc@crodrigues.org) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [63.240.77.82]) by mx1.freebsd.org (Postfix) with ESMTP id 595FB13C455 for ; Thu, 18 Jan 2007 02:29:08 +0000 (UTC) (envelope-from rodrigc@crodrigues.org) Received: from c-66-31-35-94.hsd1.ma.comcast.net ([66.31.35.94]) by comcast.net (sccrmhc12) with ESMTP id <20070118021420012002tp9ke>; Thu, 18 Jan 2007 02:14:20 +0000 Received: from c-66-31-35-94.hsd1.ma.comcast.net (localhost.crodrigues.org [127.0.0.1]) by c-66-31-35-94.hsd1.ma.comcast.net (8.13.8/8.13.8) with ESMTP id l0I2E4Xp009966 for ; Wed, 17 Jan 2007 21:14:15 -0500 (EST) (envelope-from rodrigc@c-66-31-35-94.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-31-35-94.hsd1.ma.comcast.net (8.13.8/8.13.8/Submit) id l0I2E4dY009965 for freebsd-scsi@freebsd.org; Wed, 17 Jan 2007 21:14:04 -0500 (EST) (envelope-from rodrigc) Date: Wed, 17 Jan 2007 21:13:56 -0500 From: Craig Rodrigues To: freebsd-scsi@freebsd.org Message-ID: <20070118021356.GA9941@crodrigues.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: [PATCH] gcc 4.x cleanups of cam code X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 02:29:08 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, Could someone who is more familiar with CAM take a look at the pass I did to try to clean up some gcc 4.x compiler warnings? gcc 4.x is more intolerant than gcc 3.x of mixing up assignments of char * and unsigned char *. Thanks. -- Craig Rodrigues rodrigc@crodrigues.org --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="a.txt" Index: cam.c =================================================================== RCS file: /home/ncvs/src/sys/cam/cam.c,v retrieving revision 1.10 diff -u -u -r1.10 cam.c --- cam.c 18 Apr 2006 21:53:39 -0000 1.10 +++ cam.c 18 Jan 2007 02:05:36 -0000 @@ -104,7 +104,7 @@ #endif void -cam_strvis(u_int8_t *dst, const u_int8_t *src, int srclen, int dstlen) +cam_strvis(char *dst, const char *src, int srclen, int dstlen) { /* Trim leading/trailing spaces, nulls. */ @@ -115,9 +115,9 @@ srclen--; while (srclen > 0 && dstlen > 1) { - u_int8_t *cur_pos = dst; + char *cur_pos = dst; - if (*src < 0x20 || *src >= 0x80) { + if ((u_char)*src < 0x20 || (u_char)*src >= 0x80) { /* SCSI-II Specifies that these should never occur. */ /* non-printable character */ if (dstlen > 4) { @@ -147,7 +147,7 @@ * wildcard '?' matches a single non-space character. */ int -cam_strmatch(const u_int8_t *str, const u_int8_t *pattern, int str_len) +cam_strmatch(const char *str, const char *pattern, int str_len) { while (*pattern != '\0'&& str_len > 0) { Index: cam.h =================================================================== RCS file: /home/ncvs/src/sys/cam/cam.h,v retrieving revision 1.11 diff -u -u -r1.11 cam.h --- cam.h 5 Jan 2005 22:34:34 -0000 1.11 +++ cam.h 18 Jan 2007 02:05:36 -0000 @@ -199,9 +199,9 @@ caddr_t cam_quirkmatch(caddr_t target, caddr_t quirk_table, int num_entries, int entry_size, cam_quirkmatch_t *comp_func); -void cam_strvis(u_int8_t *dst, const u_int8_t *src, int srclen, int dstlen); +void cam_strvis(char *dst, const char *src, int srclen, int dstlen); -int cam_strmatch(const u_int8_t *str, const u_int8_t *pattern, int str_len); +int cam_strmatch(const char *str, const char *pattern, int str_len); const struct cam_status_entry* cam_fetch_status_entry(cam_status status); #ifdef _KERNEL Index: cam_periph.c =================================================================== RCS file: /home/ncvs/src/sys/cam/cam_periph.c,v retrieving revision 1.64 diff -u -u -r1.64 cam_periph.c --- cam_periph.c 5 Dec 2006 07:45:27 -0000 1.64 +++ cam_periph.c 18 Jan 2007 02:05:36 -0000 @@ -648,7 +648,7 @@ mapinfo->bp[i]->b_saveaddr = mapinfo->bp[i]->b_data; /* put our pointer in the data slot */ - mapinfo->bp[i]->b_data = *data_ptrs[i]; + mapinfo->bp[i]->b_data = (caddr_t)*data_ptrs[i]; /* set the transfer length, we know it's < DFLTPHYS */ mapinfo->bp[i]->b_bufsize = lengths[i]; @@ -676,7 +676,7 @@ } /* set our pointer to the new mapped area */ - *data_ptrs[i] = mapinfo->bp[i]->b_data; + *data_ptrs[i] = (u_int8_t *)mapinfo->bp[i]->b_data; mapinfo->num_bufs_used++; } Index: scsi/scsi_cd.c =================================================================== RCS file: /home/ncvs/src/sys/cam/scsi/scsi_cd.c,v retrieving revision 1.97 diff -u -u -r1.97 scsi_cd.c --- scsi/scsi_cd.c 5 Dec 2006 07:45:27 -0000 1.97 +++ scsi/scsi_cd.c 18 Jan 2007 02:05:36 -0000 @@ -1522,7 +1522,7 @@ /* lba */ bp->bio_offset / softc->params.blksize, bp->bio_bcount / softc->params.blksize, - /* data_ptr */ bp->bio_data, + /* data_ptr */(u_int8_t *)bp->bio_data, /* dxfer_len */ bp->bio_bcount, /* sense_len */ SSD_FULL_SIZE, /* timeout */ 30000); Index: scsi/scsi_ch.c =================================================================== RCS file: /home/ncvs/src/sys/cam/scsi/scsi_ch.c,v retrieving revision 1.43 diff -u -u -r1.43 scsi_ch.c --- scsi/scsi_ch.c 5 Dec 2006 07:45:28 -0000 1.43 +++ scsi/scsi_ch.c 18 Jan 2007 02:05:36 -0000 @@ -1063,7 +1063,7 @@ struct read_element_status_header *st_hdr; struct read_element_status_page_header *pg_hdr; struct read_element_status_descriptor *desc; - caddr_t data = NULL; + u_int8_t *data = NULL; size_t size, desclen; int avail, i, error = 0; struct changer_element_status *user_data = NULL; @@ -1091,7 +1091,7 @@ * we can allocate enough storage for all of them. We assume * that the first one can fit into 1k. */ - data = (caddr_t)malloc(1024, M_DEVBUF, M_WAITOK); + data = (u_int8_t *)malloc(1024, M_DEVBUF, M_WAITOK); ccb = cam_periph_getccb(periph, /*priority*/ 1); @@ -1128,7 +1128,7 @@ * device. */ free(data, M_DEVBUF); - data = (caddr_t)malloc(size, M_DEVBUF, M_WAITOK); + data = (u_int8_t *)malloc(size, M_DEVBUF, M_WAITOK); scsi_read_element_status(&ccb->csio, /* retries */ 1, Index: scsi/scsi_da.c =================================================================== RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v retrieving revision 1.200 diff -u -u -r1.200 scsi_da.c --- scsi/scsi_da.c 5 Dec 2006 07:45:28 -0000 1.200 +++ scsi/scsi_da.c 18 Jan 2007 02:05:36 -0000 @@ -1277,7 +1277,7 @@ /*lba*/bp->bio_pblkno, /*block_count*/bp->bio_bcount / softc->params.secsize, - /*data_ptr*/ bp->bio_data, + /*data_ptr*/ (u_int8_t *)bp->bio_data, /*dxfer_len*/ bp->bio_bcount, /*sense_len*/SSD_FULL_SIZE, /*timeout*/da_default_timeout*1000); Index: scsi/scsi_low.c =================================================================== RCS file: /home/ncvs/src/sys/cam/scsi/scsi_low.c,v retrieving revision 1.26 diff -u -u -r1.26 scsi_low.c --- scsi/scsi_low.c 2 Nov 2006 00:54:33 -0000 1.26 +++ scsi/scsi_low.c 18 Jan 2007 02:05:36 -0000 @@ -150,7 +150,7 @@ /************************************************************** * Declarations **************************************************************/ -/* static */ void scsi_low_info(struct scsi_low_softc *, struct targ_info *, u_char *); +/* static */ void scsi_low_info(struct scsi_low_softc *, struct targ_info *, char *); static void scsi_low_engage(void *); static struct slccb *scsi_low_establish_ccb(struct targ_info *, struct lun_info *, scsi_low_tag_t); static int scsi_low_done(struct scsi_low_softc *, struct slccb *); @@ -2934,7 +2934,7 @@ scsi_low_restart(slp, flags, s) struct scsi_low_softc *slp; int flags; - u_char *s; + char *s; { int error; @@ -3022,7 +3022,7 @@ { struct targ_info *ti; struct slccb *cb; - u_char *s; + char *s; /* * Check select vs reselected collision. @@ -3768,7 +3768,7 @@ { struct targ_info *ti = slp->sl_Tnexus; u_int period = 0, offset = 0, speed; - u_char *s; + char *s; int error; if ((MSGIN_PERIOD(ti) >= ti->ti_maxsynch.period && @@ -4732,7 +4732,7 @@ scsi_low_info(slp, ti, s) struct scsi_low_softc *slp; struct targ_info *ti; - u_char *s; + char *s; { if (slp == NULL) @@ -4755,7 +4755,7 @@ } } -static u_char *phase[] = +static const char *phase[] = { "FREE", "ARBSTART", "SELSTART", "SELECTED", "CMDOUT", "DATA", "MSGIN", "MSGOUT", "STATIN", "DISC", "RESEL" Index: scsi/scsi_low.h =================================================================== RCS file: /home/ncvs/src/sys/cam/scsi/scsi_low.h,v retrieving revision 1.8 diff -u -u -r1.8 scsi_low.h --- scsi/scsi_low.h 5 Jan 2005 22:34:34 -0000 1.8 +++ scsi/scsi_low.h 18 Jan 2007 02:05:36 -0000 @@ -547,7 +547,7 @@ struct scsi_low_osdep_interface sl_si; #define sl_dev sl_si.si_dev struct scsi_low_osdep_funcs *sl_osdep_fp; - u_char sl_xname[16]; + char sl_xname[16]; /* our chain */ LIST_ENTRY(scsi_low_softc) sl_chain; @@ -716,7 +716,7 @@ */ #define SCSI_LOW_RESTART_HARD 1 #define SCSI_LOW_RESTART_SOFT 0 -int scsi_low_restart(struct scsi_low_softc *, int, u_char *); +int scsi_low_restart(struct scsi_low_softc *, int, char *); /* * Scsi utility fucntions Index: scsi/scsi_pt.c =================================================================== RCS file: /home/ncvs/src/sys/cam/scsi/scsi_pt.c,v retrieving revision 1.44 diff -u -u -r1.44 scsi_pt.c --- scsi/scsi_pt.c 5 Dec 2006 07:45:28 -0000 1.44 +++ scsi/scsi_pt.c 18 Jan 2007 02:05:36 -0000 @@ -505,7 +505,7 @@ bp->bio_cmd == BIO_READ, /*byte2*/0, bp->bio_bcount, - bp->bio_data, + (u_int8_t *)bp->bio_data, /*sense_len*/SSD_FULL_SIZE, /*timeout*/softc->io_timeout); Index: scsi/scsi_sa.c =================================================================== RCS file: /home/ncvs/src/sys/cam/scsi/scsi_sa.c,v retrieving revision 1.107 diff -u -u -r1.107 scsi_sa.c --- scsi/scsi_sa.c 5 Dec 2006 07:45:28 -0000 1.107 +++ scsi/scsi_sa.c 18 Jan 2007 02:05:36 -0000 @@ -1734,7 +1734,7 @@ scsi_sa_read_write(&start_ccb->csio, 0, sadone, MSG_SIMPLE_Q_TAG, (bp->bio_cmd == BIO_READ), FALSE, (softc->flags & SA_FLAG_FIXED) != 0, - length, bp->bio_data, bp->bio_bcount, SSD_FULL_SIZE, + length, (u_int8_t *)bp->bio_data, bp->bio_bcount, SSD_FULL_SIZE, IO_TIMEOUT); start_ccb->ccb_h.ccb_pflags &= ~SA_POSITION_UPDATED; Set_CCB_Type(start_ccb, SA_CCB_BUFFER_IO); Index: scsi/scsi_ses.c =================================================================== RCS file: /home/ncvs/src/sys/cam/scsi/scsi_ses.c,v retrieving revision 1.33 diff -u -u -r1.33 scsi_ses.c --- scsi/scsi_ses.c 5 Dec 2006 07:45:28 -0000 1.33 +++ scsi/scsi_ses.c 18 Jan 2007 02:05:36 -0000 @@ -676,7 +676,7 @@ } ccb = cam_periph_getccb(ssc->periph, 1); - cam_fill_csio(&ccb->csio, 0, sesdone, ddf, MSG_SIMPLE_Q_TAG, dptr, + cam_fill_csio(&ccb->csio, 0, sesdone, ddf, MSG_SIMPLE_Q_TAG, (u_int8_t *)dptr, dlen, sizeof (struct scsi_sense_data), cdbl, 60 * 1000); bcopy(cdb, ccb->csio.cdb_io.cdb_bytes, cdbl); @@ -728,7 +728,7 @@ static enctyp ses_type(void *buf, int buflen) { - unsigned char *iqd = buf; + char *iqd = buf; if (buflen < 8+SEN_ID_LEN) return (SES_NONE); @@ -762,7 +762,7 @@ return (SES_NONE); } - if (STRNCMP((char *)&iqd[SAFTE_START], "SAF-TE", SAFTE_LEN - 2) == 0) { + if (STRNCMP(&iqd[SAFTE_START], "SAF-TE", SAFTE_LEN - 2) == 0) { return (SES_SAFT); } return (SES_NONE); --qMm9M+Fa2AknHoGS-- From owner-freebsd-scsi@FreeBSD.ORG Thu Jan 18 06:12:37 2007 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2B5416A47E for ; Thu, 18 Jan 2007 06:12:37 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 8EDB313C45B for ; Thu, 18 Jan 2007 06:12:37 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id l0I6CS2s078629; Wed, 17 Jan 2007 23:12:33 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <45AF0FC6.6000709@samsco.org> Date: Wed, 17 Jan 2007 23:12:22 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: Craig Rodrigues References: <20070118021356.GA9941@crodrigues.org> In-Reply-To: <20070118021356.GA9941@crodrigues.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Wed, 17 Jan 2007 23:12:33 -0700 (MST) X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org Subject: Re: [PATCH] gcc 4.x cleanups of cam code X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 06:12:37 -0000 Craig Rodrigues wrote: > Hi, > > Could someone who is more familiar with CAM take a look > at the pass I did to try to clean up some gcc 4.x compiler warnings? > gcc 4.x is more intolerant than gcc 3.x of mixing up assignments of > char * and unsigned char *. > > Thanks. > > I'm not a language guru, nor do I care to be. However, your patch seems to imply that gcc 4.x requires an increasing amount of casting obfuscation in otherwise working source code. Is the point of gcc 4.x really to merely make C programming even more tedious, or should we be fixing our interfaces do that they work without all of the clumsy casts that you are proposing?. Below are my amateur comments: Index: cam.c =================================================================== RCS file: /home/ncvs/src/sys/cam/cam.c,v retrieving revision 1.10 diff -u -u -r1.10 cam.c --- cam.c 18 Apr 2006 21:53:39 -0000 1.10 +++ cam.c 18 Jan 2007 02:05:36 -0000 @@ -104,7 +104,7 @@ #endif void -cam_strvis(u_int8_t *dst, const u_int8_t *src, int srclen, int dstlen) +cam_strvis(char *dst, const char *src, int srclen, int dstlen) { /* Trim leading/trailing spaces, nulls. */ @@ -115,9 +115,9 @@ srclen--; while (srclen > 0 && dstlen > 1) { - u_int8_t *cur_pos = dst; + char *cur_pos = dst; - if (*src < 0x20 || *src >= 0x80) { + if ((u_char)*src < 0x20 || (u_char)*src >= 0x80) { /* SCSI-II Specifies that these should never occur. */ /* non-printable character */ if (dstlen > 4) { You've gone from an unsigned quantity to a signed quantity. On the down side, this breaks the old API, though in a fairly trivial way. On the plus side, it brings the function more in line with the standard strvis(3) function. Not sure exactly how I feel about this. Since cam.c and cam.h are shared with userland, have you verified that this works there too? @@ -147,7 +147,7 @@ * wildcard '?' matches a single non-space character. */ int -cam_strmatch(const u_int8_t *str, const u_int8_t *pattern, int str_len) +cam_strmatch(const char *str, const char *pattern, int str_len) { while (*pattern != '\0'&& str_len > 0) { Same as above. Index: cam.h =================================================================== RCS file: /home/ncvs/src/sys/cam/cam.h,v retrieving revision 1.11 diff -u -u -r1.11 cam.h --- cam.h 5 Jan 2005 22:34:34 -0000 1.11 +++ cam.h 18 Jan 2007 02:05:36 -0000 @@ -199,9 +199,9 @@ caddr_t cam_quirkmatch(caddr_t target, caddr_t quirk_table, int num_entries, int entry_size, cam_quirkmatch_t *comp_func); -void cam_strvis(u_int8_t *dst, const u_int8_t *src, int srclen, int dstlen); +void cam_strvis(char *dst, const char *src, int srclen, int dstlen); -int cam_strmatch(const u_int8_t *str, const u_int8_t *pattern, int str_len); +int cam_strmatch(const char *str, const char *pattern, int str_len); const struct cam_status_entry* cam_fetch_status_entry(cam_status status); #ifdef _KERNEL Again, if you're going to go forward with this kind of change, please make sure that at least camcontrol still compiles. Index: cam_periph.c =================================================================== RCS file: /home/ncvs/src/sys/cam/cam_periph.c,v retrieving revision 1.64 diff -u -u -r1.64 cam_periph.c --- cam_periph.c 5 Dec 2006 07:45:27 -0000 1.64 +++ cam_periph.c 18 Jan 2007 02:05:36 -0000 @@ -648,7 +648,7 @@ mapinfo->bp[i]->b_saveaddr = mapinfo->bp[i]->b_data; /* put our pointer in the data slot */ - mapinfo->bp[i]->b_data = *data_ptrs[i]; + mapinfo->bp[i]->b_data = (caddr_t)*data_ptrs[i]; /* set the transfer length, we know it's < DFLTPHYS */ mapinfo->bp[i]->b_bufsize = lengths[i]; @@ -676,7 +676,7 @@ } /* set our pointer to the new mapped area */ - *data_ptrs[i] = mapinfo->bp[i]->b_data; + *data_ptrs[i] = (u_int8_t *)mapinfo->bp[i]->b_data; mapinfo->num_bufs_used++; } I've seen this cast in other patches that have been pushed out for gcc 4.x. It seems like every single assignment involving bp->b_data in the kernel is going to need a clumsy cast from now on. How thrilling. I wonder if there is a better way to do this. Also, I thought that the use of caddr_t had been frowned upon many years ago. Index: scsi/scsi_cd.c =================================================================== RCS file: /home/ncvs/src/sys/cam/scsi/scsi_cd.c,v retrieving revision 1.97 diff -u -u -r1.97 scsi_cd.c --- scsi/scsi_cd.c 5 Dec 2006 07:45:27 -0000 1.97 +++ scsi/scsi_cd.c 18 Jan 2007 02:05:36 -0000 @@ -1522,7 +1522,7 @@ /* lba */ bp->bio_offset / softc->params.blksize, bp->bio_bcount / softc->params.blksize, - /* data_ptr */ bp->bio_data, + /* data_ptr */(u_int8_t *)bp->bio_data, /* dxfer_len */ bp->bio_bcount, /* sense_len */ SSD_FULL_SIZE, /* timeout */ 30000); More b_data fun. I wonder what /sys/kern and /sys/geom look like =-( I won't bother pasting in all of the scsi_low.[ch] changes, but I assume that their API change has been confirmed to not any drivers that rely on them, yes? Index: scsi/scsi_ses.c =================================================================== RCS file: /home/ncvs/src/sys/cam/scsi/scsi_ses.c,v retrieving revision 1.33 diff -u -u -r1.33 scsi_ses.c --- scsi/scsi_ses.c 5 Dec 2006 07:45:28 -0000 1.33 +++ scsi/scsi_ses.c 18 Jan 2007 02:05:36 -0000 @@ -676,7 +676,7 @@ } ccb = cam_periph_getccb(ssc->periph, 1); - cam_fill_csio(&ccb->csio, 0, sesdone, ddf, MSG_SIMPLE_Q_TAG, dptr, + cam_fill_csio(&ccb->csio, 0, sesdone, ddf, MSG_SIMPLE_Q_TAG, (u_int8_t *)dptr, dlen, sizeof (struct scsi_sense_data), cdbl, 60 * 1000); bcopy(cdb, ccb->csio.cdb_io.cdb_bytes, cdbl); Blah, another ugly cast. Avoiding the cast looks to require a lot of work, but I don't know if it's ultimately the right thing. @@ -728,7 +728,7 @@ static enctyp ses_type(void *buf, int buflen) { - unsigned char *iqd = buf; + char *iqd = buf; if (buflen < 8+SEN_ID_LEN) return (SES_NONE); @@ -762,7 +762,7 @@ return (SES_NONE); } - if (STRNCMP((char *)&iqd[SAFTE_START], "SAF-TE", SAFTE_LEN - 2) == 0) { + if (STRNCMP(&iqd[SAFTE_START], "SAF-TE", SAFTE_LEN - 2) == 0) { return (SES_SAFT); } return (SES_NONE); Finally, a cast is removed! Scott From owner-freebsd-scsi@FreeBSD.ORG Thu Jan 18 09:36:49 2007 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A33A16A416 for ; Thu, 18 Jan 2007 09:36:49 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id 250D213C4A7 for ; Thu, 18 Jan 2007 09:36:49 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id A45616E02C; Thu, 18 Jan 2007 20:36:45 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 8B45727405; Thu, 18 Jan 2007 20:36:45 +1100 (EST) Date: Thu, 18 Jan 2007 20:36:44 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Scott Long In-Reply-To: <45AF0FC6.6000709@samsco.org> Message-ID: <20070118191016.N3367@besplex.bde.org> References: <20070118021356.GA9941@crodrigues.org> <45AF0FC6.6000709@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Craig Rodrigues , freebsd-scsi@freebsd.org Subject: Re: [PATCH] gcc 4.x cleanups of cam code X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 09:36:49 -0000 On Wed, 17 Jan 2007, Scott Long wrote: > Craig Rodrigues wrote: >> >> Could someone who is more familiar with CAM take a look That's not me. >> at the pass I did to try to clean up some gcc 4.x compiler warnings? >> gcc 4.x is more intolerant than gcc 3.x of mixing up assignments of >> char * and unsigned char *. > I'm not a language guru, nor do I care to be. However, your patch seems I play better as a language guru for 1 language. > to imply that gcc 4.x requires an increasing amount of casting > obfuscation in otherwise working source code. Is the point of gcc 4.x > really to merely make C programming even more tedious, or should we be > fixing our interfaces do that they work without all of the clumsy casts > that you are proposing?. Below are my amateur comments: Both. More warnings make programming more tedious, especially if you try to be careful and use lots of types, but we should be fixing interfaces and not hiding bugs behind casts. > Index: cam.c > =================================================================== > RCS file: /home/ncvs/src/sys/cam/cam.c,v > retrieving revision 1.10 > diff -u -u -r1.10 cam.c > --- cam.c 18 Apr 2006 21:53:39 -0000 1.10 > +++ cam.c 18 Jan 2007 02:05:36 -0000 > @@ -104,7 +104,7 @@ > #endif > > void > -cam_strvis(u_int8_t *dst, const u_int8_t *src, int srclen, int dstlen) > +cam_strvis(char *dst, const char *src, int srclen, int dstlen) I think the main problem addressed by this set of patches is that gcc finally started warning about the error of mixing pointers to plain char with pointers to unsigned char. If chars are signed, then there is a type mismatch, and if chars are unsigned then the code is unportable. This error is most common in code that tries to use the correct types. Old sloppy code tends to use plain chars for everything and not worry about the sign conversion problems or 1's complement problems from this. Here the code was apparently trying to be even more careful and use u_int8_t instead of u_char. Userland strvis() just uses char *, but that doesn't make it sloppy, since strings actually are char * in userland. I think cam_strvis()'s use of u_int8_t is correct too, since CAM wants to make visible non-strings which should be declared as u_int8_t[] in SCSI data structures. Howver, the only relevant non- strings are vendor[], product[] and revision[], and these are declared as plain char[], hence the type mismatch. I think the bug is in the declaration of these non-strings. AFAIK (not far), the non-strings are specified by the SCSI standard as consisting of 8-bit bytes. scsi_all.h uses u_int8_t for most byte data except these. > { > > /* Trim leading/trailing spaces, nulls. */ > @@ -115,9 +115,9 @@ > srclen--; > > while (srclen > 0 && dstlen > 1) { > - u_int8_t *cur_pos = dst; > + char *cur_pos = dst; > > - if (*src < 0x20 || *src >= 0x80) { > + if ((u_char)*src < 0x20 || (u_char)*src >= 0x80) { > /* SCSI-II Specifies that these should never occur. > */ > /* non-printable character */ > if (dstlen > 4) { > > You've gone from an unsigned quantity to a signed quantity. On the down > side, this breaks the old API, though in a fairly trivial way. On the plus > side, it brings the function more in line with the standard strvis(3) > function. Not sure exactly how I feel about this. Since cam.c and cam.h are > shared with userland, have you verified that this > works there too? For conversions between chars and u_int8_t, something like this is needed, but it is better to start with u_int8_t and avoid casts if possible. Casts should never be applied before range checks because they may move the value in or out of the range. In the above, the casts are just ugly and not needed. Range checking has already been broken in the 1's complement case (the invalid value (u_int8_t)0xFF is -0 as a signed 8-bit char, and of course things would be completely broken if the data is 8 bits but char is > 8 bits (maybe this can't happen if u_int8_t exists). The casts in the above are to avoid changing the semantics of cam_strvis() provided problems have not already occurred (they might even give identical object code). With more uglyness, API problems can probably be fixed up too. The code would reduce to what the old sign mismatches did, but to be strictly correct it has to access the 8-bit unsigned chars (it that is what the were) using something like memcpy() to get at the individual bits. The bits can then be interpreted. > ... > Same as above. Poisoning for sign mismatches is like const poisoning, but worse, since any change in signedness risks sign extension bugs. > Index: cam_periph.c > =================================================================== > RCS file: /home/ncvs/src/sys/cam/cam_periph.c,v > retrieving revision 1.64 > diff -u -u -r1.64 cam_periph.c > --- cam_periph.c 5 Dec 2006 07:45:27 -0000 1.64 > +++ cam_periph.c 18 Jan 2007 02:05:36 -0000 > @@ -648,7 +648,7 @@ > mapinfo->bp[i]->b_saveaddr = mapinfo->bp[i]->b_data; > > /* put our pointer in the data slot */ > - mapinfo->bp[i]->b_data = *data_ptrs[i]; > + mapinfo->bp[i]->b_data = (caddr_t)*data_ptrs[i]; > > /* set the transfer length, we know it's < DFLTPHYS */ > mapinfo->bp[i]->b_bufsize = lengths[i]; > @@ -676,7 +676,7 @@ > } > > /* set our pointer to the new mapped area */ > - *data_ptrs[i] = mapinfo->bp[i]->b_data; > + *data_ptrs[i] = (u_int8_t *)mapinfo->bp[i]->b_data; > > mapinfo->num_bufs_used++; > } > > I've seen this cast in other patches that have been pushed out for gcc > 4.x. It seems like every single assignment involving bp->b_data in the > kernel is going to need a clumsy cast from now on. How thrilling. I > wonder if there is a better way to do this. Also, I thought that the > use of caddr_t had been frowned upon many years ago. b_data is still (bogusly) caddr_t, so it needs to be fixed someday and it's surprising that more casts aren't needed when assigning to it. The above seems to be just another case of the sign poisoning and not closely related to b_data. caddr_t is char *, so it has signedness, so with warnings about signedness mismatches for pointers you can now only assign pointers to signed quantities to it. C has a grandfather clause (kludge) which allows void * to be misspelled as char * in some contexts without a diagnostic for type mismatches which are much larger than signedness mismatches being required. I wonder if the new warnings are allowed with this. Maybe we are asking for them. > =================================================================== > RCS file: /home/ncvs/src/sys/cam/scsi/scsi_ses.c,v > retrieving revision 1.33 > diff -u -u -r1.33 scsi_ses.c > --- scsi/scsi_ses.c 5 Dec 2006 07:45:28 -0000 1.33 > +++ scsi/scsi_ses.c 18 Jan 2007 02:05:36 -0000 > @@ -676,7 +676,7 @@ > } > > ccb = cam_periph_getccb(ssc->periph, 1); > - cam_fill_csio(&ccb->csio, 0, sesdone, ddf, MSG_SIMPLE_Q_TAG, dptr, > + cam_fill_csio(&ccb->csio, 0, sesdone, ddf, MSG_SIMPLE_Q_TAG, > (u_int8_t *)dptr, > dlen, sizeof (struct scsi_sense_data), cdbl, 60 * 1000); > bcopy(cdb, ccb->csio.cdb_io.cdb_bytes, cdbl); > > > Blah, another ugly cast. Avoiding the cast looks to require a lot of work, > but I don't know if it's ultimately the right thing. Also, an expansion of a lines beyond 80 characters and subsequent mangling of the long line in the mail. > @@ -762,7 +762,7 @@ > return (SES_NONE); > } > > - if (STRNCMP((char *)&iqd[SAFTE_START], "SAF-TE", SAFTE_LEN - 2) == 0) > { > + if (STRNCMP(&iqd[SAFTE_START], "SAF-TE", SAFTE_LEN - 2) == 0) { > return (SES_SAFT); > } > return (SES_NONE); > > > Finally, a cast is removed! Any code that tries to be very careful and use u_int8_t for byte data has this problem when interfacing with standard string functions. Bruce From owner-freebsd-scsi@FreeBSD.ORG Fri Jan 19 09:23:56 2007 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4EC6016A407 for ; Fri, 19 Jan 2007 09:23:56 +0000 (UTC) (envelope-from y.pankov@irbis.net.ru) Received: from mail.irbis.net.ru (mail.irbis.net.ru [194.186.18.2]) by mx1.freebsd.org (Postfix) with ESMTP id B5FCA13C428 for ; Fri, 19 Jan 2007 09:23:55 +0000 (UTC) (envelope-from y.pankov@irbis.net.ru) Received: from [192.168.0.64] (baator.local [192.168.0.64]) by mail.irbis.net.ru (Postfix) with ESMTP id 887E062D4B0 for ; Fri, 19 Jan 2007 12:11:58 +0300 (MSK) Message-ID: <45B08B5E.4080202@irbis.net.ru> Date: Fri, 19 Jan 2007 12:11:58 +0300 From: Yuri Pankov User-Agent: Thunderbird 1.5.0.9 (X11/20070116) MIME-Version: 1.0 To: freebsd-scsi@freebsd.org X-Enigmail-Version: 0.94.1.0 OpenPGP: id=CE301A55 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.7/2466/Fri Jan 19 02:49:11 2007 on mail.irbis.net.ru X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (mail.irbis.net.ru [194.186.18.2]); Fri, 19 Jan 2007 12:11:59 +0300 (MSK) Subject: ahd0: Invalid Sequencer interrupt occurred. X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 09:23:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm getting this message at boot with lot of debug output related to Adaptec AIC7901 Ultra320 SCSI adapter. Other than that, system seems to be working without problems. Does this message show possible problems or it may be silently discarded? FreeBSD 6.2-RELEASE/i386, GENERIC kernel (was the same with 6.0-RELEASE, GENERIC). relevant messages from dmesg: ahd0: port 0xb800-0xb8ff,0xb400-0xb4ff mem 0xfc5fe000-0xfc5fffff irq 27 at device 1.0 on pci2 ahd0: [GIANT-LOCKED] aic7901: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 50-66Mhz, 512 SCBs Waiting 5 seconds for SCSI devices to settle ahd0: Invalid Sequencer interrupt occurred. >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< ahd0: Dumping Card State at program address 0x230 Mode 0x0 Card was paused INTSTAT[0x0] SELOID[0x1] SELID[0x0] HS_MAILBOX[0x0] INTCTL[0x80]:(SWTMINTMASK) SEQINTSTAT[0x0] SAVED_MODE[0x11] DFFSTAT[0x33]:(CURRFIFO_NONE|FIFO0FREE|FIFO1FREE) SCSISIGI[0x0]:(P_DATAOUT) SCSIPHASE[0x0] SCSIBUS[0x0] LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE) SCSISEQ0[0x0] SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI) SEQCTL0[0x0] SEQINTCTL[0x6]:(INTMASK1|INTMASK2) SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0] QFREEZE_COUNT[0x2] KERNEL_QFREEZE_COUNT[0x2] MK_MESSAGE_SCB[0xff00] MK_MESSAGE_SCSIID[0xff] SSTAT0[0x0] SSTAT1[0x0] SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0x0] SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO) LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x0] SCB Count = 16 CMDS_PENDING = 0 LASTSCB 0xffff CURRSCB 0xe NEXTSCB 0xff40 qinstart = 28 qinfifonext = 28 QINFIFO: WAITING_TID_QUEUES: Pending list: Total 0 Kernel Free SCB list: 14 15 1 2 3 4 5 6 7 8 9 10 11 12 13 0 Sequencer Complete DMA-inprog list: Sequencer Complete list: Sequencer DMA-Up and Complete list: Sequencer On QFreeze and Complete list: ahd0: FIFO0 Free, LONGJMP == 0x8000, SCB 0xf SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) ahd0: FIFO1 Free, LONGJMP == 0x8063, SCB 0xe SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) LQIN: 0x8 0x0 0x0 0xf 0x0 0x1 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 ahd0: LQISTATE = 0x0, LQOSTATE = 0x0, OPTIONMODE = 0x52 ahd0: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x1 ahd0: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0 SIMODE0[0xc]:(ENOVERRUN|ENIOERR) CCSCBCTL[0x4]:(CCSCBDIR) ahd0: REG0 == 0x4460, SINDEX = 0x180, DINDEX = 0x104 ahd0: SCBPTR == 0xf, SCB_NEXT == 0xff40, SCB_NEXT2 == 0xe CDB 12 20 0 80 88 76 STACK: 0x22b 0x1 0x0 0x0 0x0 0x0 0x0 0x0 <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x29 0x2 0x2 0x0 0x0 0x0 Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x29 0x2 0x2 0x0 0x0 0x0 da0 at ahd0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) da1 at ahd0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) Thanks, Yuri -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFsIterfDNc84wGlURAtXcAJ9M5YJFjCuwSyGdlpTbi9wB/46RVgCgiJHZ p8dWcZo9x3/F//1aM8r2GS8= =4/by -----END PGP SIGNATURE----- From owner-freebsd-scsi@FreeBSD.ORG Fri Jan 19 09:34:40 2007 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1862F16A4A7 for ; Fri, 19 Jan 2007 09:34:40 +0000 (UTC) (envelope-from y.pankov@irbis.net.ru) Received: from mail.irbis.net.ru (mail.irbis.net.ru [194.186.18.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7ABF113C4A5 for ; Fri, 19 Jan 2007 09:34:38 +0000 (UTC) (envelope-from y.pankov@irbis.net.ru) Received: from [192.168.0.64] (baator.local [192.168.0.64]) by mail.irbis.net.ru (Postfix) with ESMTP id 2852C62D4AF for ; Fri, 19 Jan 2007 12:34:32 +0300 (MSK) Message-ID: <45B090A9.8040207@irbis.net.ru> Date: Fri, 19 Jan 2007 12:34:33 +0300 From: Yuri Pankov User-Agent: Thunderbird 1.5.0.9 (X11/20070116) MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <45B08B5E.4080202@irbis.net.ru> In-Reply-To: <45B08B5E.4080202@irbis.net.ru> X-Enigmail-Version: 0.94.1.0 OpenPGP: id=CE301A55 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.7/2466/Fri Jan 19 02:49:11 2007 on mail.irbis.net.ru X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (mail.irbis.net.ru [194.186.18.2]); Fri, 19 Jan 2007 12:34:33 +0300 (MSK) Subject: Re: ahd0: Invalid Sequencer interrupt occurred. X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 09:34:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yuri Pankov wrote: > Hi, > > I'm getting this message at boot with lot of debug output related to > Adaptec AIC7901 Ultra320 SCSI adapter. Other than that, system seems to > be working without problems. Does this message show possible problems or > it may be silently discarded? > Actually I've found lots of references to this message on the list. Sorry for the noise, I must improve my search skills. Yuri -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFsJCorfDNc84wGlURAiBBAJ9/U6/YsQMFXPzREYzqRlFfG0R2bgCfULcU YFGp9AppldmGybURJ9AaOWE= =RClb -----END PGP SIGNATURE----- From owner-freebsd-scsi@FreeBSD.ORG Fri Jan 19 16:27:00 2007 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8208316A405 for ; Fri, 19 Jan 2007 16:27:00 +0000 (UTC) (envelope-from jesskung@brel.com) Received: from smtp41.singnet.com.sg (smtp41.singnet.com.sg [165.21.103.142]) by mx1.freebsd.org (Postfix) with ESMTP id CD15513C455 for ; Fri, 19 Jan 2007 16:26:59 +0000 (UTC) (envelope-from jesskung@brel.com) Received: from [127.0.0.1] ([58.185.251.102]) by smtp41.singnet.com.sg (8.13.8/8.13.6) with ESMTP id l0JENJog004333 for ; Fri, 19 Jan 2007 22:23:22 +0800 Message-ID: <45B0D4AC.9020801@brel.com> Date: Fri, 19 Jan 2007 22:24:44 +0800 From: Jessica Kung User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: FreeBSD harddisk error - read (06) medium error info unrecovered pls help... X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 16:27:00 -0000 Dear netizens Help! I am running FreeBSD and encountered the following error in booting up. (da0:sym 0:0:0) read (06) CDB: 8 0 0 bf 10 0 (da0:sym 0:0:0) Medium error info: c8 csi: 0, 0, 0, c8 asci: 11, c (da0:sym 0:0:0) Unrecovered read error - recommend rewrite the data field replacable unit: 6 b sks: 80, 74 Any help is much appreciated! Thanks in advanced! Jessica