From owner-freebsd-scsi@FreeBSD.ORG Sun Dec 18 22:41:49 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A48E216A41F for ; Sun, 18 Dec 2005 22:41:49 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7B1A43D67 for ; Sun, 18 Dec 2005 22:41:48 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by wproxy.gmail.com with SMTP id i31so990327wra for ; Sun, 18 Dec 2005 14:41:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=b/G/KWhjgjje2ubbKo42VAsxTN8kK3wXdaqHUyhCS2fXe7Pguz7TpDxSNOevo/9vqD0m3taqCCqPeRiZ2/5dQrNuOi/nfWpLR2BIXkLMobLZWcjmN4H1dFNTfuG9woahU2Gw6hHx2qNv7OZA1VKx4WRDMF8/98/acHGce9iCatk= Received: by 10.65.250.13 with SMTP id c13mr1008365qbs; Sun, 18 Dec 2005 14:41:47 -0800 (PST) Received: by 10.65.155.20 with HTTP; Sun, 18 Dec 2005 14:41:47 -0800 (PST) Message-ID: <7579f7fb0512181441t26a8a90bv5970d3dcd8eef5c6@mail.gmail.com> Date: Sun, 18 Dec 2005 17:41:47 -0500 From: Matthew Jacob To: Dan Langille In-Reply-To: <43A46030.31260.5B3110E@localhost> MIME-Version: 1.0 References: <43A46030.31260.5B3110E@localhost> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-scsi@freebsd.org Subject: Re: no tape - ENXIO - device not configured 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, 18 Dec 2005 22:41:49 -0000 open the control device- that's what it's there for. On 12/17/05, Dan Langille wrote: > > You probably know that I'm a developer on the Bacula > project. One of the issues we're trying to > improve now is using the tape drive when there is no tape. > > Basically Bacula needs to open() the tape drive so that it can > read/write it. On both Linux and Solaris, it is possible to open the > drive with O_NONBLOCK and get a descriptor that can be used for > ioctl() calls and providing there is a tape in the drive, it can be > used for read() and write(). > > On FreeBSD, if there is no tape in the drive, the OS always > immediately returns errno=3DENXIO "Device not configured". This means > that on FreeBSD, if there is no tape in the drive, that drive is > totally unusable by Bacula. > > Another developer, who actually does most of the tape writing > routines had two suggestions: > > 1. Modify Bacula and system dependent code that opens the control > device to see if a tape drive is really there or not, and then > rewrite the tape driver code to deal with the fact that if you cannot > open a device, it may really be there, and you should continue trying > to open it between asking the user to mount it. This is clearly > possible. > > 2. Consider implementing something in FreeBSD as exists on at least > Linux and Solaris -- i.e. a means to open the drive and get a valid > file descriptor. If you read/write/rewind/... a drive opened and > there is no tape, it should either return EIO or better ENOMEDIUM. > > Comments? > > -- > Dan Langille : http://www.langille.org/ > BSDCan - The Technical BSD Conference - http://www.bsdcan.org/ > > > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > From owner-freebsd-scsi@FreeBSD.ORG Sun Dec 18 22:48:23 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B4C716A41F for ; Sun, 18 Dec 2005 22:48:23 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A5E843D53 for ; Sun, 18 Dec 2005 22:48:22 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by wproxy.gmail.com with SMTP id i31so990889wra for ; Sun, 18 Dec 2005 14:48:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=DCbNxzWFtzaBg1qyeyQ3DTZ2msqTEZHsvkHorQSJ5EYMbDo4Y3xGzvIHLhs1cTJR5IDty+286tBVs3WMax6tPGQq6NkUu+yUDXkiHQM5Iizbc3gcAWDMSpLLv+O7zcAtNjBulsl6quQ7OQtexak9Un1DruFnuN6dDTIn5DfUSrA= Received: by 10.65.132.20 with SMTP id j20mr2402421qbn; Sun, 18 Dec 2005 14:48:21 -0800 (PST) Received: by 10.65.155.20 with HTTP; Sun, 18 Dec 2005 14:48:21 -0800 (PST) Message-ID: <7579f7fb0512181448x1dc4b3f4m9d5112cc6bc9fc1a@mail.gmail.com> Date: Sun, 18 Dec 2005 17:48:21 -0500 From: Matthew Jacob To: Kern Sibbald In-Reply-To: <200512151122.34949.kern@sibbald.com> MIME-Version: 1.0 References: <200512151122.34949.kern@sibbald.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-scsi@freebsd.org Subject: Re: Tape drive handling on FreeBSD 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, 18 Dec 2005 22:48:23 -0000 The first paragraph of mtio(4) describes the usage of a control device. On 12/15/05, Kern Sibbald wrote: > > Hello, > > We correponded a couple of years ago when Bacula was experiencing data > loss > at the end of tapes -- it turned out to be a pthreads bug that suppressed > the early end of tape warning. > > I have a new problem, and if you cannot help, please > direct me in the right direction. > > Basically Bacula (network backup program) needs to open() the tape drive > so > that it can read/write it. On both Linux and Solaris, it is possible to > open > the drive with O_NONBLOCK and get a descriptor that can be used for > ioctl() > calls and providing there is a tape in the drive, it can be used for > read() > and write(). > > On FreeBSD, if there is no tape in the drive, the OS always immediately > returns errno=3DENXIO "Device not configured". This means that on FreeBS= D, > if > there is no tape in the drive, that drive is totally unusable by > Bacula. Now > it seems to me that there are two solutions: > > 1. Modify Bacula and system dependent code that opens the control device > to > see if a tape drive is really there or not, and then rewrite the tape > driver > code to deal with the fact that if you cannot open a device, it may reall= y > be > there, and you should continue trying to open it between asking the user > to > mount it. This is clearly possible. > > 2. Consider implementing something in FreeBSD as exists on at least Linux > and > Solaris -- i.e. a means to open the drive and get a valid file descriptor= . > If you read/write/rewind/... a drive opened and there is no tape, it > should > either return EIO or better ENOMEDIUM. > > Comments? > > -- > Best regards, > > Kern > > ("> > /\ > V_V > > ------------------------------------------------------- > > -- > Best regards, > > Kern > > ("> > /\ > V_V > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > From owner-freebsd-scsi@FreeBSD.ORG Mon Dec 19 09:34:52 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66A4716A42C for ; Mon, 19 Dec 2005 09:34:52 +0000 (GMT) (envelope-from kern@sibbald.com) Received: from matou.sibbald.com (matou.sibbald.com [194.158.240.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17C3F43D60 for ; Mon, 19 Dec 2005 09:34:50 +0000 (GMT) (envelope-from kern@sibbald.com) Received: from rufus (rufus [192.168.68.112]) by matou.sibbald.com (8.13.4/8.13.4) with ESMTP id jBJ9YmtC001830; Mon, 19 Dec 2005 10:34:49 +0100 From: Kern Sibbald To: Matthew Jacob Date: Mon, 19 Dec 2005 10:34:52 +0100 User-Agent: KMail/1.8.2 References: <200512151122.34949.kern@sibbald.com> <7579f7fb0512181448x1dc4b3f4m9d5112cc6bc9fc1a@mail.gmail.com> In-Reply-To: <7579f7fb0512181448x1dc4b3f4m9d5112cc6bc9fc1a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512191034.52756.kern@sibbald.com> Cc: freebsd-scsi@freebsd.org Subject: Re: Tape drive handling on FreeBSD 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, 19 Dec 2005 09:34:52 -0000 On Sunday 18 December 2005 23:48, Matthew Jacob wrote: > The first paragraph of mtio(4) describes the usage of a control device. Yes, thanks. I've already read that and other sections of the man pages, and it is true that the .ctl device allows one to figure out if a tape drive really exists or not. The problem is: 1. It is system dependent -- I would like to see some standardization of the Unix API from system to system where it is reasonable, practical, and doesn't break everything. 2. The errno that is currently returned by an empt tape drive during an open() is "incorrect" or at the least misleading. 3. The API that you currently have doesn't work correctly with Bacula, which was originally designed on Linux and Solaris -- it penalizes FreeBSD Bacula users. Since the FreeBSD way of doing things is the minority in my little Unix world, it is unlikely (though possible) that I will rewrite my code. 4. There are other shortcomings of the SCSI driver that penalize FreeBSD users compared to Solaris and Linux that I would like to discuss as well (ability to have the driver efficiently space to the end of the medium and keep track of the file position). Actually, I am really shocked how poor the "Unix" tape interface is (this has nothing to do with FreeBSD in particular). There is no standard way to set tape drive options, there is no standard way to figure out if a tape drive exists and what options it has set for it (blocking, two eof, density, compression, ...). Probably most annoying, there is no standard way to know if a tape is mounted or not. My main interest is to try to discuss what possibilities exist for changing (unifying) the API (or there is also a small chance that I am missing something ...). If no possibility of discussion/changes exists, so be it. > > On 12/15/05, Kern Sibbald wrote: > > Hello, > > > > We correponded a couple of years ago when Bacula was experiencing data > > loss > > at the end of tapes -- it turned out to be a pthreads bug that suppressed > > the early end of tape warning. > > > > I have a new problem, and if you cannot help, please > > direct me in the right direction. > > > > Basically Bacula (network backup program) needs to open() the tape drive > > so > > that it can read/write it. On both Linux and Solaris, it is possible to > > open > > the drive with O_NONBLOCK and get a descriptor that can be used for > > ioctl() > > calls and providing there is a tape in the drive, it can be used for > > read() > > and write(). > > > > On FreeBSD, if there is no tape in the drive, the OS always immediately > > returns errno=ENXIO "Device not configured". This means that on FreeBSD, > > if > > there is no tape in the drive, that drive is totally unusable by > > Bacula. Now > > it seems to me that there are two solutions: > > > > 1. Modify Bacula and system dependent code that opens the control device > > to > > see if a tape drive is really there or not, and then rewrite the tape > > driver > > code to deal with the fact that if you cannot open a device, it may > > really be > > there, and you should continue trying to open it between asking the user > > to > > mount it. This is clearly possible. > > > > 2. Consider implementing something in FreeBSD as exists on at least Linux > > and > > Solaris -- i.e. a means to open the drive and get a valid file > > descriptor. If you read/write/rewind/... a drive opened and there is no > > tape, it should > > either return EIO or better ENOMEDIUM. > > > > Comments? > > > > -- > > Best regards, > > > > Kern > > > > ("> > > /\ > > V_V > > > > ------------------------------------------------------- > > > > -- > > Best regards, > > > > Kern > > > > ("> > > /\ > > V_V > > _______________________________________________ > > freebsd-scsi@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" -- Best regards, Kern ("> /\ V_V From owner-freebsd-scsi@FreeBSD.ORG Mon Dec 19 11:03:02 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CF3516A41F for ; Mon, 19 Dec 2005 11:03:02 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9754043D83 for ; Mon, 19 Dec 2005 11:02:35 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id jBJB2X0x011350 for ; Mon, 19 Dec 2005 11:02:33 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id jBJB2UQe011344 for freebsd-scsi@freebsd.org; Mon, 19 Dec 2005 11:02:30 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 19 Dec 2005 11:02:30 GMT Message-Id: <200512191102.jBJB2UQe011344@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter 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, 19 Dec 2005 11:03:02 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/05/03] kern/27059 scsi [sym] SCSI subsystem hangs under heavy lo o [2001/06/29] kern/28508 scsi problems with backup to Tandberg SLR40 st o [2002/06/17] kern/39388 scsi ncr/sym drivers fail with 53c810 and more o [2002/07/22] kern/40895 scsi wierd kernel / device driver bug o [2003/05/24] kern/52638 scsi [panic] SCSI U320 on SMP server won't run s [2003/09/30] kern/57398 scsi [mly] Current fails to install on mly(4) o [2003/12/26] kern/60598 scsi wire down of scsi devices conflicts with o [2003/12/27] kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C81 s [2004/01/10] kern/61165 scsi [panic] kernel page fault after calling c o [2004/12/02] kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5 o [2005/06/04] kern/81887 scsi [aac] Adaptec SCSI 2130S aac0: GetDeviceP o [2005/12/12] kern/90282 scsi [sym] SCSI bus resets cause loss of ch de 12 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/12/06] kern/23314 scsi aic driver fails to detect Adaptec 1520B o [2001/08/15] kern/29727 scsi [amr] [patch] amr_enquiry3 structure in a o [2002/02/23] kern/35234 scsi World access to /dev/pass? (for scanner) o [2002/06/02] kern/38828 scsi [feature request] DPT PM2012B/90 doesn't o [2002/10/29] kern/44587 scsi dev/dpt/dpt.h is missing defines required o [2003/10/01] kern/57469 scsi [scsi] [patch] Quirk for Conner CP3500 o [2005/01/12] kern/76178 scsi [ahd] Problem with ahd and large SCSI Rai 7 problems total. From owner-freebsd-scsi@FreeBSD.ORG Mon Dec 19 19:12:11 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09E4A16A41F for ; Mon, 19 Dec 2005 19:12:11 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41E1C43D45 for ; Mon, 19 Dec 2005 19:12:10 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so1109984wra for ; Mon, 19 Dec 2005 11:12:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=gkCRCo0fcMatrmdEhWKvPwM/Zzz7/20rHfUJ5OYPLhC9aEUWsitGZOwsHTVnksk212eDJUhGGAFd/5n3t+OBJKnilISlvUyj3wHoF9QZwiLY20idrcLVnSjqaAYLpbtqXaCA8jDgi+fz7TGtNEdzhQl91Xd4qMs0ik/vAOKy2Ms= Received: by 10.65.141.7 with SMTP id t7mr5636495qbn; Mon, 19 Dec 2005 11:12:09 -0800 (PST) Received: by 10.65.155.20 with HTTP; Mon, 19 Dec 2005 11:12:09 -0800 (PST) Message-ID: <7579f7fb0512191112n3a5d8a5ai6e27587a39c7023b@mail.gmail.com> Date: Mon, 19 Dec 2005 14:12:09 -0500 From: Matthew Jacob To: Kern Sibbald In-Reply-To: <200512191034.52756.kern@sibbald.com> MIME-Version: 1.0 References: <200512151122.34949.kern@sibbald.com> <7579f7fb0512181448x1dc4b3f4m9d5112cc6bc9fc1a@mail.gmail.com> <200512191034.52756.kern@sibbald.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-scsi@freebsd.org Subject: Re: Tape drive handling on FreeBSD 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, 19 Dec 2005 19:12:11 -0000 On 12/19/05, Kern Sibbald wrote: > On Sunday 18 December 2005 23:48, Matthew Jacob wrote: > > The first paragraph of mtio(4) describes the usage of a control device. > > Yes, thanks. I've already read that and other sections of the man pages, > and > it is true that the .ctl device allows one to figure out if a tape drive > really exists or not. The problem is: > > 1. It is system dependent -- I would like to see some standardization of > the > Unix API from system to system where it is reasonable, practical, and > doesn't > break everything. ..... My problem is that if I change the FreeBSD API, it breaks current usage. Otherwise, there is no true tape device API in Unix. Look at any existing backup package that is multi-platform. It breaks each platform into different vectors that abstract the differences. Don't get me wrong- I'm not promoting that there should differences. I'm observing that nearly thirty years of Unix shows that there are and that th= e way that those differences have been handled successfully by dozens of tape backup packages (albeit with grumbling). > 2. The errno that is currently returned by an empt tape drive during an > open() > is "incorrect" or at the least misleading. The value that Solaris returns (EIO) for trying to open a tape (!O_NONBLOCK= ) when no tape is loaded (i.e., fails TUR) is no less misleading. Your complaint here is that ERRNO is not sufficient. It isn't. > 3. The API that you currently have doesn't work correctly with Bacula, > which > was originally designed on Linux and Solaris -- it penalizes FreeBSD > Bacula > users. Since the FreeBSD way of doing things is the minority in my littl= e > Unix world, it is unlikely (though possible) that I will rewrite my code. Well, that is your privilege. > 4. There are other shortcomings of the SCSI driver that penalize FreeBSD > users > compared to Solaris and Linux that I would like to discuss as well > (ability > to have the driver efficiently space to the end of the medium and keep > track > of the file position). Despite the fact that I'm the nominal maintainer, I probably won't do that much more. I put in a fair amount of time some years back, spent around 7500$ of my own personal money to buy tape drives to do testing with. That said, the return value for this was more than what I got for writing the Solaris tape driver (which is shockingly and pathetically bad, but has also remained relatively unchanged for over 10 years). Still, the things that penalize FreeBSD are many- the tape driver is hardly a leading candidate. > Actually, I am really shocked how poor the "Unix" tape interface is (this > has > nothing to do with FreeBSD in particular). There is no standard way to se= t > tape drive options, there is no standard way to figure out if a tape driv= e > exists and what options it has set for it (blocking, two eof, density, > compression, ...). Probably most annoying, there is no standard way to > know > if a tape is mounted or not. Yes. > My main interest is to try to discuss what possibilities exist for > changing > (unifying) the API (or there is also a small chance that I am missing > something ...). If no possibility of discussion/changes exists, so be it= . a) If you can get a consensus amongs more FreeBSD tape clients than you tha= t there *should* be convergence to, e.g., Linux, or Solaris, I certainly woul= d be interested. Get the Amanda and Arkeia folks on board, and we might be able to get enough consensus to override the concerns of people even more conservative than I am. b) If you rewrite Bacula to actually be more platform independent you might serve yourself better. Having maintained some of the nsrmmd code for NetWorker/Legato, I *am* sympathetic to your concerns here. However, the other thing I've learned, very very very very painfully, is that making changes to existing tape interfaces (no matter how broken) will almost certainly enrage and break more than it fixes as everyone who uses said interfaces usually is caught by surprise when things change. I suppose that we could have a separate SA device entry point that mandated different tape semantics- that might help minimize breakage at the risk of complexity. Part of the problem is that you probably are asking for a different state machine in the driver as well. Look- dialogue is good, but temper it with some realities please. From owner-freebsd-scsi@FreeBSD.ORG Mon Dec 19 22:06:36 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80E9116A41F for ; Mon, 19 Dec 2005 22:06:36 +0000 (GMT) (envelope-from kern@sibbald.com) Received: from matou.sibbald.com (matou.sibbald.com [194.158.240.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AEFD43D8A for ; Mon, 19 Dec 2005 22:06:29 +0000 (GMT) (envelope-from kern@sibbald.com) Received: from rufus (rufus [192.168.68.112]) by matou.sibbald.com (8.13.4/8.13.4) with ESMTP id jBJM6R2E014260; Mon, 19 Dec 2005 23:06:27 +0100 From: Kern Sibbald To: Matthew Jacob Date: Mon, 19 Dec 2005 23:06:31 +0100 User-Agent: KMail/1.8.2 References: <200512151122.34949.kern@sibbald.com> <200512191034.52756.kern@sibbald.com> <7579f7fb0512191112n3a5d8a5ai6e27587a39c7023b@mail.gmail.com> In-Reply-To: <7579f7fb0512191112n3a5d8a5ai6e27587a39c7023b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512192306.31821.kern@sibbald.com> Cc: freebsd-scsi@freebsd.org Subject: Re: Tape drive handling on FreeBSD 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, 19 Dec 2005 22:06:36 -0000 On Monday 19 December 2005 20:12, Matthew Jacob wrote: > On 12/19/05, Kern Sibbald wrote: > > On Sunday 18 December 2005 23:48, Matthew Jacob wrote: > > > The first paragraph of mtio(4) describes the usage of a control device. > > > > Yes, thanks. I've already read that and other sections of the man pages, > > and > > it is true that the .ctl device allows one to figure out if a tape drive > > really exists or not. The problem is: > > > > 1. It is system dependent -- I would like to see some standardization of > > the > > Unix API from system to system where it is reasonable, practical, and > > doesn't > > break everything. > > ..... > > My problem is that if I change the FreeBSD API, it breaks current usage. I'm proposing changes that I do not believe will break current usage. > > Otherwise, there is no true tape device API in Unix. Look at any existing > backup package that is multi-platform. It breaks each platform into > different vectors that abstract the differences. What a waste of programming time ... > > Don't get me wrong- I'm not promoting that there should differences. I'm > observing that nearly thirty years of Unix shows that there are and that > the way that those differences have been handled successfully by dozens of > tape backup packages (albeit with grumbling). Well, I'm one of the ones grumbling. Maybe after 30 years someone will listen. > > > 2. The errno that is currently returned by an empt tape drive during an > > open() > > is "incorrect" or at the least misleading. > > The value that Solaris returns (EIO) for trying to open a tape > (!O_NONBLOCK) when no tape is loaded (i.e., fails TUR) is no less > misleading. Yes, I agree. Linux returns ENOMEDIUM. Too bad this isn't standard, but I can deal with that. > > Your complaint here is that ERRNO is not sufficient. It isn't. Yes, I agree. > > > 3. The API that you currently have doesn't work correctly with Bacula, > > which > > was originally designed on Linux and Solaris -- it penalizes FreeBSD > > Bacula > > users. Since the FreeBSD way of doing things is the minority in my > > little Unix world, it is unlikely (though possible) that I will rewrite > > my code. > > Well, that is your privilege. I don't consider it a privilege just spending what little time I have on the high priority items. > > > 4. There are other shortcomings of the SCSI driver that penalize FreeBSD > > users > > compared to Solaris and Linux that I would like to discuss as well > > (ability > > to have the driver efficiently space to the end of the medium and keep > > track > > of the file position). > > Despite the fact that I'm the nominal maintainer, I probably won't do that > much more. I put in a fair amount of time some years back, spent around > 7500$ of my own personal money to buy tape drives to do testing with. Yes, I understand. I've been there too. Take a look at the Bacula "contribution" page some day when you are bored. > That > said, the return value for this was more than what I got for writing the > Solaris tape driver (which is shockingly and pathetically bad, but has also > remained relatively unchanged for over 10 years). Maybe the Solaris drive is shockingly bad from your point of view, but from my point of view, it works, is efficient, and allows the user to control the drive in a reasonable way. > Still, the things that > penalize FreeBSD are many- the tape driver is hardly a leading candidate. I'm not a FreeBSD expert, but for me the tape drive is a good place to start. It doesn't need much ... > > > Actually, I am really shocked how poor the "Unix" tape interface is (this > > has > > nothing to do with FreeBSD in particular). There is no standard way to > > set tape drive options, there is no standard way to figure out if a tape > > drive exists and what options it has set for it (blocking, two eof, > > density, compression, ...). Probably most annoying, there is no standard > > way to know > > if a tape is mounted or not. > > Yes. > > > My main interest is to try to discuss what possibilities exist for > > changing > > (unifying) the API (or there is also a small chance that I am missing > > something ...). If no possibility of discussion/changes exists, so be > > it. > > a) If you can get a consensus amongs more FreeBSD tape clients than you > that there *should* be convergence to, e.g., Linux, or Solaris, I certainly > would be interested. Get the Amanda and Arkeia folks on board, and we might > be able to get enough consensus to override the concerns of people even > more conservative than I am. It seems to me that the Amanda project is dead. I seen no activity and their developers receive but do not respond to my emails. I'd be willing to try, but I think the things I am proposing at this stage would change nothing for them -- see below. > > b) If you rewrite Bacula to actually be more platform independent you might > serve yourself better. Having maintained some of the nsrmmd code for > NetWorker/Legato, I *am* sympathetic to your concerns here. However, the > other thing I've learned, very very very very painfully, is that making > changes to existing tape interfaces (no matter how broken) will almost > certainly enrage and break more than it fixes as everyone who uses said > interfaces usually is caught by surprise when things change. I cannot answer this because I already consider Bacula to be extremely platform independent simply because it uses very elementary features so it doesn't really need any platform dependent code. > > I suppose that we could have a separate SA device entry point that mandated > different tape semantics- that might help minimize breakage at the risk of > complexity. Part of the problem is that you probably are asking for a > different state machine in the driver as well. Not knowing the driver, I may be wrong here, but I hope I am not asking for a different state machine. I am asking for some tweaks that would bring FreeBSD forward and more in line with some other platforms without breaking anything (I may be wrong though ...). > > Look- dialogue is good, but temper it with some realities please. OK, here are a couple of real possibilities (at least from my point of view): 1. I believe that one can modify the FreeBSD tape API to become more compatible with Solaris and Linux without breaking any programs -- simply use their "trick" of allowing an open() in all cases to succeed if O_NONBLOCK is set. I think this is an ugly kludge, but that is how they do it. If there is no tape in the drive, then return a file descriptor with no read and no write permission, and modify them when a tape is mounted. 2. Certainly someone can certainly figure out some magic ioctl() that allows the user to set a mode so that the SCSI driver will do a forward space file (big number) when an ioctl( EOM ) issued. The driver can do it *much* more efficiently and quickly than a program can. The penalty is a bit of speed, but the gain is that the correct file number can be returned. Am I wrong? Yes, when things work, I know it is hard to get excited about making changes. -- Best regards, Kern ("> /\ V_V From owner-freebsd-scsi@FreeBSD.ORG Mon Dec 19 23:20:30 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A044416A41F for ; Mon, 19 Dec 2005 23:20:30 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F69143D55 for ; Mon, 19 Dec 2005 23:20:29 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by wproxy.gmail.com with SMTP id i32so1124635wra for ; Mon, 19 Dec 2005 15:20:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=SxmuoXXIIH0wSz9YNE29SVmw2nqvOtAIF9CEpDFXKzSvmeGFIfxIJhnoAnd5IgDZz+IpfxkoSfRBgpgkv2tem9sCLSCI7rVoct1DPJJS3i4YcyHOs6jgzveVUuYgqKjEv9Fp7pqC8fg90jPsLF+mMW3wA2D2x+O/eAwjE1ehYCE= Received: by 10.65.157.12 with SMTP id j12mr3631317qbo; Mon, 19 Dec 2005 15:20:29 -0800 (PST) Received: by 10.65.155.20 with HTTP; Mon, 19 Dec 2005 15:20:28 -0800 (PST) Message-ID: <7579f7fb0512191520t484add63p40d81e2754897028@mail.gmail.com> Date: Mon, 19 Dec 2005 18:20:28 -0500 From: Matthew Jacob To: Kern Sibbald In-Reply-To: <200512192306.31821.kern@sibbald.com> MIME-Version: 1.0 References: <200512151122.34949.kern@sibbald.com> <200512191034.52756.kern@sibbald.com> <7579f7fb0512191112n3a5d8a5ai6e27587a39c7023b@mail.gmail.com> <200512192306.31821.kern@sibbald.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-scsi@freebsd.org Subject: Re: Tape drive handling on FreeBSD 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, 19 Dec 2005 23:20:30 -0000 >Am I wrong? Yes, when things work, I know it is hard to get excited about making changes. But the point here is that they don't work. > > 1. I believe that one can modify the FreeBSD tape API to become more > compatible with Solaris and Linux without breaking any programs -- simply > use > their "trick" of allowing an open() in all cases to succeed if O_NONBLOCK > is > set. I think this is an ugly kludge, but that is how they do it. If ther= e > is > no tape in the drive, then return a file descriptor with no read and no > write > permission, and modify them when a tape is mounted. That's probably do-able. 2. Certainly someone can certainly figure out some magic ioctl() that allow= s > the user to set a mode so that the SCSI driver will do a forward space > file > (big number) when an ioctl( EOM ) issued. The driver can do it *much* > more > efficiently and quickly than a program can. The penalty is a bit of > speed, > but the gain is that the correct file number can be returned. I guess in this entire thread I missed what you're looking for here (have a heart- I'm on a 800x600 borrowed win98 machine in Toledo Ohio right now). I= s the problem here that you *don't* want to do 'space to EOD' when EOM is issued? That is, you don't want to lose your actual relative tape position information when seeking to append? From owner-freebsd-scsi@FreeBSD.ORG Tue Dec 20 09:18:09 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A895716A41F for ; Tue, 20 Dec 2005 09:18:09 +0000 (GMT) (envelope-from kern@sibbald.com) Received: from matou.sibbald.com (matou.sibbald.com [194.158.240.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1946843D64 for ; Tue, 20 Dec 2005 09:18:05 +0000 (GMT) (envelope-from kern@sibbald.com) Received: from rufus (rufus [192.168.68.112]) by matou.sibbald.com (8.13.4/8.13.4) with ESMTP id jBK9I30Y028736; Tue, 20 Dec 2005 10:18:03 +0100 From: Kern Sibbald To: Matthew Jacob Date: Tue, 20 Dec 2005 10:18:07 +0100 User-Agent: KMail/1.8.2 References: <200512151122.34949.kern@sibbald.com> <200512192306.31821.kern@sibbald.com> <7579f7fb0512191520t484add63p40d81e2754897028@mail.gmail.com> In-Reply-To: <7579f7fb0512191520t484add63p40d81e2754897028@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512201018.07905.kern@sibbald.com> Cc: freebsd-scsi@freebsd.org Subject: Re: Tape drive handling on FreeBSD 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, 20 Dec 2005 09:18:09 -0000 On Tuesday 20 December 2005 00:20, Matthew Jacob wrote: > >Am I wrong? Yes, when things work, I know it is hard to get excited about > > making changes. > > But the point here is that they don't work. :-) > > > 1. I believe that one can modify the FreeBSD tape API to become more > > compatible with Solaris and Linux without breaking any programs -- simply > > use > > their "trick" of allowing an open() in all cases to succeed if O_NONBLOCK > > is > > set. I think this is an ugly kludge, but that is how they do it. If > > there is > > no tape in the drive, then return a file descriptor with no read and no > > write > > permission, and modify them when a tape is mounted. > > That's probably do-able. The only problem I can imagine is if someone already uses O_NONBLOCK on an open() call and expects it to fail if there is no tape in the drive. This seems a bit unlikely, but a bit of documentation can avoid most problems. > > 2. Certainly someone can certainly figure out some magic ioctl() that > allows > > > the user to set a mode so that the SCSI driver will do a forward space > > file > > (big number) when an ioctl( EOM ) issued. The driver can do it *much* > > more > > efficiently and quickly than a program can. The penalty is a bit of > > speed, > > but the gain is that the correct file number can be returned. > > I guess in this entire thread I missed what you're looking for here (have a > heart- I'm on a 800x600 borrowed win98 machine in Toledo Ohio right now). Sorry to hit you at a bad time. > Is the problem here that you *don't* want to do 'space to EOD' when EOM is > issued? That is, you don't want to lose your actual relative tape position > information when seeking to append? Yes, exactly. Since Bacula maintains the file/block positions of jobs/data in a catalog, it will refuse to append to a tape if the actual EOM of the tape does not agree with the catalog. A discrepency can easily occur if, while writing a tape, the OS crashes (a power loss of course) ... Kern From owner-freebsd-scsi@FreeBSD.ORG Tue Dec 20 15:03:44 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79A5E16A41F for ; Tue, 20 Dec 2005 15:03:44 +0000 (GMT) (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 179F543D55 for ; Tue, 20 Dec 2005 15:03:43 +0000 (GMT) (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 1Eoj1i-000BBD-Ln; Tue, 20 Dec 2005 17:03:42 +0200 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Matthew Jacob Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Dec 2005 17:03:42 +0200 From: Danny Braniss Message-ID: Cc: freebsd-scsi@freebsd.org Subject: (no subject) 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, 20 Dec 2005 15:03:44 -0000 hi, isp panics under 6.0/amd64, is this known? i'll try to get a trace but that involves fighting my way through the bios. the same box, with an 6.0/i386 kernel is ok. danny From owner-freebsd-scsi@FreeBSD.ORG Tue Dec 20 20:49:35 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0BD816A41F for ; Tue, 20 Dec 2005 20:49:35 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC63043D5A for ; Tue, 20 Dec 2005 20:49:34 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by wproxy.gmail.com with SMTP id i7so219794wra for ; Tue, 20 Dec 2005 12:49:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ZIeO3FcAjWCR18v/fspRSUerVhJO1qtHL8lXX7RolU4U7O20htPDJGG7zHRdlazj2ji8K3hSQKT5ZMv0R27WZT1xnZOGuT/aPfS8tPgFQo5lJ5FzsIt1vDn0o5+93HPJiQ4I46QMQdRN5NizH+WG2ZI104jFtzs65goTB434Tak= Received: by 10.65.132.20 with SMTP id j20mr4645218qbn; Tue, 20 Dec 2005 12:49:30 -0800 (PST) Received: by 10.65.155.20 with HTTP; Tue, 20 Dec 2005 12:49:29 -0800 (PST) Message-ID: <7579f7fb0512201249k595e2eai62467a0c0e670451@mail.gmail.com> Date: Tue, 20 Dec 2005 12:49:29 -0800 From: Matthew Jacob To: Kern Sibbald In-Reply-To: <200512201018.07905.kern@sibbald.com> MIME-Version: 1.0 References: <200512151122.34949.kern@sibbald.com> <200512192306.31821.kern@sibbald.com> <7579f7fb0512191520t484add63p40d81e2754897028@mail.gmail.com> <200512201018.07905.kern@sibbald.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-scsi@freebsd.org Subject: Re: Tape drive handling on FreeBSD 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, 20 Dec 2005 20:49:35 -0000 > The only problem I can imagine is if someone already uses O_NONBLOCK on a= n > open() call and expects it to fail if there is no tape in the drive. Thi= s > seems a bit unlikely, but a bit of documentation can avoid most problems. *cough* Documentation didn't help you :-). I'll try and do a bit of work on it over the next week or so but I can't test until I get home and hook up a tape drive (and find a frickin' piece o= f DTL media for it). Poke me periodically at my private address. > Is the problem here that you *don't* want to do 'space to EOD' when EOM i= s > > issued? That is, you don't want to lose your actual relative tape > position > > information when seeking to append? > > Yes, exactly. Since Bacula maintains the file/block positions of > jobs/data in > a catalog, it will refuse to append to a tape if the actual EOM of the > tape > does not agree with the catalog. A discrepency can easily occur if, whil= e > writing a tape, the OS crashes (a power loss of course) ... Can't use use block location stuff? Again- let's move this discussion to my private mail address unless anyone else on freebsd-scsi wants to join in. From owner-freebsd-scsi@FreeBSD.ORG Wed Dec 21 13:37:39 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB26C16A41F for ; Wed, 21 Dec 2005 13:37:39 +0000 (GMT) (envelope-from dan@langille.org) Received: from m21.unixathome.org (m21.unixathome.org [205.150.199.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C08B43D60 for ; Wed, 21 Dec 2005 13:37:39 +0000 (GMT) (envelope-from dan@langille.org) Received: from localhost (localhost [205.150.199.217]) by m21.unixathome.org (Postfix) with ESMTP id 3EEDCC37D; Wed, 21 Dec 2005 08:37:38 -0500 (EST) Received: from m21.unixathome.org ([205.150.199.217]) by localhost (m21.unixathome.org [205.150.199.217]) (amavisd-new, port 10024) with ESMTP id 23636-07; Wed, 21 Dec 2005 08:37:35 -0500 (EST) Received: from bast.unixathome.org (bast.unixathome.org [70.26.229.230]) by m21.unixathome.org (Postfix) with ESMTP id 0DAADBF57; Wed, 21 Dec 2005 08:37:34 -0500 (EST) Received: from [10.55.0.99] (wocker.unixathome.org [10.55.0.99]) by bast.unixathome.org (Postfix) with ESMTP id AA8173D3B; Wed, 21 Dec 2005 08:37:34 -0500 (EST) From: "Dan Langille" To: Matthew Jacob , freebsd-scsi@freebsd.org Date: Wed, 21 Dec 2005 08:37:34 -0500 MIME-Version: 1.0 Message-ID: <43A9144E.22636.E437919@dan.langille.org> Priority: normal In-reply-to: <7579f7fb0512201249k595e2eai62467a0c0e670451@mail.gmail.com> References: <200512201018.07905.kern@sibbald.com> X-mailer: Pegasus Mail for Windows (4.31) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at unixathome.org Cc: Kern Sibbald Subject: Re: Tape drive handling on FreeBSD 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: Wed, 21 Dec 2005 13:37:39 -0000 On 20 Dec 2005 at 12:49, Matthew Jacob wrote: > > The only problem I can imagine is if someone already uses O_NONBLOCK on an > > open() call and expects it to fail if there is no tape in the drive. This > > seems a bit unlikely, but a bit of documentation can avoid most problems. > > > > *cough* > > Documentation didn't help you :-). > > I'll try and do a bit of work on it over the next week or so but I can't > test until I get home and hook up a tape drive (and find a frickin' piece of > DTL media for it). > > Poke me periodically at my private address. I can give you access to a machine with a DLT drive attached. It's running 5.4 and it's where Kern does his regression testing. Please email me your ssh-key and if possible, the IP address[es] you use. -- Dan Langille : http://www.langille.org/ BSDCan - The Technical BSD Conference - http://www.bsdcan.org/ From owner-freebsd-scsi@FreeBSD.ORG Wed Dec 21 20:37:58 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6685616A41F for ; Wed, 21 Dec 2005 20:37:58 +0000 (GMT) (envelope-from huzeyfe@cc.kou.edu.tr) Received: from cc.kou.edu.tr (cc.kou.edu.tr [194.27.72.80]) by mx1.FreeBSD.org (Postfix) with SMTP id 27AC543D5D for ; Wed, 21 Dec 2005 20:37:56 +0000 (GMT) (envelope-from huzeyfe@cc.kou.edu.tr) Received: (qmail 7632 invoked by uid 1009); 21 Dec 2005 22:37:39 -0000 X-Mail-Scanner: Scanned by qSheff 1.0-r4 (http://www.enderunix.org/qsheff/) Received: from localhost.kou.edu.tr (HELO cc.kou.edu.tr) (127.0.0.1) by cc.kou.edu.tr with SMTP; 21 Dec 2005 22:37:37 -0000 Received: from 81.215.151.240 (SquirrelMail authenticated user huzeyfe) by cc.kou.edu.tr with HTTP; Wed, 21 Dec 2005 22:37:37 -0000 (UTC) Message-ID: <61921.81.215.151.240.1135204657.squirrel@cc.kou.edu.tr> Date: Wed, 21 Dec 2005 22:37:37 -0000 (UTC) From: "Huzeyfe ONAL" To: freebsd-scsi@freebsd.org User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-9 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: FreeBSD installation error on IBM x226 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: huzeyfe@enderunix.org List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2005 20:37:58 -0000 Hi, I want to install FreeBSD 6.0 on IBM x226 but it gives "ips0: resetting adapter, this may take up to 5 minutes" error before starting installation..I wait 10~ minutes but there is no action.. Is there any patch for this or solution to install FreeBSD on it? Thanks.. -- -- Hata yapmayan insan genellikle her hangi bir şey yapmıyor demektir. "The man who makes no mistakes does not usually make anything." --Bishop W. C. Magee