From owner-freebsd-scsi Sun Apr 14 4: 9: 1 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from van-laarhoven.org (ap-z-5ab8.adsl.wanadoo.nl [212.129.218.184]) by hub.freebsd.org (Postfix) with SMTP id 272C837B419 for ; Sun, 14 Apr 2002 04:08:57 -0700 (PDT) Received: (qmail 52266 invoked from network); 14 Apr 2002 11:08:56 -0000 Received: from heather.van-laarhoven.org (10.66.0.2) by uitsmijter.van-laarhoven.org with SMTP; 14 Apr 2002 11:08:56 -0000 Date: Sun, 14 Apr 2002 13:08:56 +0200 (CEST) From: Nick Hibma To: Kenneth W Cochran Cc: "freebsd-scsi@freebsd.org" , "freebsd-stable@freebsd.org" Subject: Re: Status, USB/Olympus E-10 In-Reply-To: <200204131541.LAA12983@world.std.com> Message-ID: <20020414130742.V36693-100000@heather.van-laarhoven.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > >The fact that it reboots without reason is very very strange indeed. If > >that is the case, check that your machine is grounded properly. Static > >electricity nuked my Win2k box every once in a while when I did a sync > >with my Palm. > > Grounding definitely not a problem; system doesn't panic > until I try to mount the device. Based on another message > thread in -stable ("very old bug") I wonder if it might be > related: the E-10 is supposedly a MS-DOS filesystem, & I > think it is readonly (not sure, though). Does it, or does it NOT panic on mount? If it panics the problem should be easy to track down. If it doesn't panic there is a fat chance that it still is something hardware related. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 14 6:18: 0 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from TheWorld.com (pcls2.std.com [199.172.62.104]) by hub.freebsd.org (Postfix) with ESMTP id 11A5B37B404; Sun, 14 Apr 2002 06:17:47 -0700 (PDT) Received: from shell.TheWorld.com (trebor@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.9.3/8.9.3) with ESMTP id JAA32474; Sun, 14 Apr 2002 09:17:43 -0400 Received: (from kwc@localhost) by shell.TheWorld.com (8.9.3/8.9.3) id JAA5477193; Sun, 14 Apr 2002 09:17:43 -0400 (EDT) Date: Sun, 14 Apr 2002 09:17:43 -0400 (EDT) From: Kenneth W Cochran Message-Id: <200204141317.JAA5477193@shell.TheWorld.com> To: Nick Hibma Subject: Re: Status, USB/Olympus E-10 Cc: freebsd-stable@freebsd.org, freebsd-scsi@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Date: Sun, 14 Apr 2002 13:08:56 +0200 (CEST) >From: Nick Hibma >To: Kenneth W Cochran >cc: "freebsd-scsi@freebsd.org" , > "freebsd-stable@freebsd.org" >Subject: Re: Status, USB/Olympus E-10 > >> >The fact that it reboots without reason is very very strange indeed. If >> >that is the case, check that your machine is grounded properly. Static >> >electricity nuked my Win2k box every once in a while when I did a sync >> >with my Palm. >> >> Grounding definitely not a problem; system doesn't panic >> until I try to mount the device. Based on another message >> thread in -stable ("very old bug") I wonder if it might be >> related: the E-10 is supposedly a MS-DOS filesystem, & I >> think it is readonly (not sure, though). > >Does it, or does it NOT panic on mount? If it panics the problem should >be easy to track down. If it doesn't panic there is a fat chance that it >still is something hardware related. Yes, it panics on mount. Sequence: 0. usbd running 1. Connect camera - camera is detected & identified additinally, camcontrol works, i.e. rescan detects proper SCSI device(s) 2. (try) mounting it - immediate panic & reboot, panic is a divide by zero someplace Previous email indicated that it appears to be a problem with the "geometry" of the device. It gets a zero someplace in "CHS"(?), thus the divide by zero. -kc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 15 0:47:40 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from van-laarhoven.org (ap-z-5ab8.adsl.wanadoo.nl [212.129.218.184]) by hub.freebsd.org (Postfix) with SMTP id 6E8C737B404 for ; Mon, 15 Apr 2002 00:47:25 -0700 (PDT) Received: (qmail 57342 invoked from network); 15 Apr 2002 07:47:23 -0000 Received: from heather.van-laarhoven.org (10.66.0.2) by uitsmijter.van-laarhoven.org with SMTP; 15 Apr 2002 07:47:23 -0000 Date: Mon, 15 Apr 2002 09:47:22 +0200 (CEST) From: Nick Hibma To: Kenneth W Cochran Cc: "freebsd-stable@freebsd.org" , "freebsd-scsi@freebsd.org" Subject: Re: Status, USB/Olympus E-10 In-Reply-To: <200204141317.JAA5477193@shell.TheWorld.com> Message-ID: <20020415094031.O36693-100000@heather.van-laarhoven.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Could you do me a favour and recompile your kernel for kernel debugging, with these additional lines in your kernel configuration (in /sys/i386/conf): makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols options DDB Then panic your machine while after it has been idle for about a minute or two to reduce the chance of damage (boot it, leave it running for 2 minutes till the drive LED is quiet, log in as root, connect the USB device, type sync, wait 30 seconds, type mount -> the machine panics) At the DDB prompt that appears, type 'trace' and the machine will display a backtrace of functions. Write down the function names. Send me that list of functions and send me the output of ident /sys/dev/usb/*.[ch] /sys/cam/*.[ch] /sys/cam/scsi/*.[ch] (the revision numbers of the files your using. Running with a debug kernel should be no problem and not much slower than running with a production kernel. The only problem is that the machine no longer can be used in unattended mode as it drops into the debugger on panic. But on a desktop machine this is not a problem (except from when you are using X as you won't be able to see the ddb prompt, so it will appear that the machine has simply frozen. Type 'c' to continue). Cheers, Nick On Sun, 14 Apr 2002, Kenneth W Cochran wrote: > >Date: Sun, 14 Apr 2002 13:08:56 +0200 (CEST) > >From: Nick Hibma > >To: Kenneth W Cochran > >cc: "freebsd-scsi@freebsd.org" , > > "freebsd-stable@freebsd.org" > >Subject: Re: Status, USB/Olympus E-10 > > > >> >The fact that it reboots without reason is very very strange indeed. If > >> >that is the case, check that your machine is grounded properly. Static > >> >electricity nuked my Win2k box every once in a while when I did a sync > >> >with my Palm. > >> > >> Grounding definitely not a problem; system doesn't panic > >> until I try to mount the device. Based on another message > >> thread in -stable ("very old bug") I wonder if it might be > >> related: the E-10 is supposedly a MS-DOS filesystem, & I > >> think it is readonly (not sure, though). > > > >Does it, or does it NOT panic on mount? If it panics the problem should > >be easy to track down. If it doesn't panic there is a fat chance that it > >still is something hardware related. > > Yes, it panics on mount. > Sequence: > 0. usbd running > 1. Connect camera - camera is detected & identified > additinally, camcontrol works, i.e. rescan detects proper > SCSI device(s) > 2. (try) mounting it - immediate panic & reboot, panic is a > divide by zero someplace > > Previous email indicated that it appears to be a problem > with the "geometry" of the device. It gets a zero > someplace in "CHS"(?), thus the divide by zero. > > -kc > -- n_hibma@van-laarhoven.org http://www.van-laarhoven.org/ n_hibma@FreeBSD.org http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 15 2:36:31 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mailbox.univie.ac.at (mailbox.univie.ac.at [131.130.1.27]) by hub.freebsd.org (Postfix) with ESMTP id 16E0137B426 for ; Mon, 15 Apr 2002 02:36:10 -0700 (PDT) Received: from pcle2.cc.univie.ac.at (pcle2.cc.univie.ac.at [131.130.2.177]) by mailbox.univie.ac.at (8.12.2/8.12.2) with ESMTP id g3F9ZkOx1511546; Mon, 15 Apr 2002 11:35:50 +0200 Date: Mon, 15 Apr 2002 11:35:46 +0200 (CEST) From: Lukas Ertl X-X-Sender: le@pcle2.cc.univie.ac.at To: Paul Saab Cc: freebsd-scsi@freebsd.org Subject: Re: ciss driver and tagged queuing In-Reply-To: <20020413224048.GA6046@elvis.mu.org> Message-ID: <20020415113126.V171-100000@pcle2.cc.univie.ac.at> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 13 Apr 2002, Paul Saab wrote: > Yea.. Mike and I discovered that the CAM sim was being frozen but never > being unfrozen. Can you try this patch? Hi, thanks for the patch. Yes, the processes now don't lock up anymore, but the performance issues are still there. Read performance has improved, but write performance is still low. regards, le --=20 Lukas Ertl eMail: l.ertl@univie.ac.at UNIX-Systemadministrator Tel.: (+43 1) 4277-14073 Zentraler Informatikdienst (ZID) Fax.: (+43 1) 4277-9140 der Universit=E4t Wien http://mailbox.univie.ac.at/~le/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 15 2:40:27 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 9A42037B400 for ; Mon, 15 Apr 2002 02:40:23 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1000) id 7646AAE147; Mon, 15 Apr 2002 02:40:23 -0700 (PDT) Date: Mon, 15 Apr 2002 02:40:23 -0700 From: Paul Saab To: Lukas Ertl Cc: freebsd-scsi@freebsd.org Subject: Re: ciss driver and tagged queuing Message-ID: <20020415094023.GA61115@elvis.mu.org> References: <20020413224048.GA6046@elvis.mu.org> <20020415113126.V171-100000@pcle2.cc.univie.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020415113126.V171-100000@pcle2.cc.univie.ac.at> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Lukas Ertl (l.ertl@univie.ac.at) wrote: > > On Sat, 13 Apr 2002, Paul Saab wrote: > > > Yea.. Mike and I discovered that the CAM sim was being frozen but never > > being unfrozen. Can you try this patch? > > thanks for the patch. Yes, the processes now don't lock up anymore, but > the performance issues are still there. Read performance has improved, but > write performance is still low. Can you clarify "low"? What is your setup? How fast are the disks? I can try to reproduce the same setup here, but you have to give us an idea of what you're doing. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 15 3:18:53 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mailbox.univie.ac.at (mailbox.univie.ac.at [131.130.1.27]) by hub.freebsd.org (Postfix) with ESMTP id 58CFB37B404 for ; Mon, 15 Apr 2002 03:18:49 -0700 (PDT) Received: from pcle2.cc.univie.ac.at (pcle2.cc.univie.ac.at [131.130.2.177]) by mailbox.univie.ac.at (8.12.2/8.12.2) with ESMTP id g3FAGkOx1069780; Mon, 15 Apr 2002 12:17:26 +0200 Date: Mon, 15 Apr 2002 12:16:46 +0200 (CEST) From: Lukas Ertl X-X-Sender: le@pcle2.cc.univie.ac.at To: Paul Saab Cc: freebsd-scsi@freebsd.org Subject: Re: ciss driver and tagged queuing In-Reply-To: <20020415094023.GA61115@elvis.mu.org> Message-ID: <20020415114324.N171-100000@pcle2.cc.univie.ac.at> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 15 Apr 2002, Paul Saab wrote: > Lukas Ertl (l.ertl@univie.ac.at) wrote: > > > > On Sat, 13 Apr 2002, Paul Saab wrote: > > > > > Yea.. Mike and I discovered that the CAM sim was being frozen but nev= er > > > being unfrozen. Can you try this patch? > > > > thanks for the patch. Yes, the processes now don't lock up anymore, but > > the performance issues are still there. Read performance has improved, = but > > write performance is still low. > > Can you clarify "low"? What is your setup? How fast are the disks? > I can try to reproduce the same setup here, but you have to give us an > idea of what you're doing. Ok, I've listed my benchmark results at . Short breakdown of my setup: Two identical Compaq PL DL380G2 w/1133 MHz Pentium III and 1280 MB RAM. Box I ("Transtec SCSI/IDE Raid") has an Adaptec 3960D Ultra160 SCSI adapter inside, which is connected to a Transtec SCSI/IDE Raid box (speaks SCSI on the outside, has 12 80GB Seagate IDE disks inside, 11 of them are configure as RAID5). Box II ("Compaq Smart Array") has a Compaq Smart Array 5302 controller inside, which is connected to a Compaq Smart Array with 7 72GB Compaq SCSI disks (10k RPM), also configured as RAID5. (This is the box that was patched.) Stripe size of both RAID5 is 64k. regards, le --=20 Lukas Ertl eMail: l.ertl@univie.ac.at UNIX-Systemadministrator Tel.: (+43 1) 4277-14073 Zentraler Informatikdienst (ZID) Fax.: (+43 1) 4277-9140 der Universit=E4t Wien http://mailbox.univie.ac.at/~le/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 15 10:25:59 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 3B4F837B404 for ; Mon, 15 Apr 2002 10:25:58 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1000) id 10C9BAE03F; Mon, 15 Apr 2002 10:25:58 -0700 (PDT) Date: Mon, 15 Apr 2002 10:25:58 -0700 From: Paul Saab To: Lukas Ertl Cc: freebsd-scsi@freebsd.org Subject: Re: ciss driver and tagged queuing Message-ID: <20020415172558.GA78808@elvis.mu.org> References: <20020415094023.GA61115@elvis.mu.org> <20020415114324.N171-100000@pcle2.cc.univie.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020415114324.N171-100000@pcle2.cc.univie.ac.at> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Lukas Ertl (l.ertl@univie.ac.at) wrote: > Ok, I've listed my benchmark results at > . I assume you let the parity initialize on the compaq? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 15 10:49:52 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mailbox.univie.ac.at (mailbox.univie.ac.at [131.130.1.27]) by hub.freebsd.org (Postfix) with ESMTP id DF85C37B400 for ; Mon, 15 Apr 2002 10:49:49 -0700 (PDT) Received: from adslle.cc.univie.ac.at (adslle.cc.univie.ac.at [131.130.102.11]) by mailbox.univie.ac.at (8.12.2/8.12.2) with ESMTP id g3FHnbHB1562782; Mon, 15 Apr 2002 19:49:41 +0200 Date: Mon, 15 Apr 2002 19:49:37 +0200 (CEST) From: Lukas Ertl X-X-Sender: le@leelou.in.tern To: Paul Saab Cc: Lukas Ertl , Subject: Re: ciss driver and tagged queuing In-Reply-To: <20020415172558.GA78808@elvis.mu.org> Message-ID: <20020415194610.C25861-100000@leelou.in.tern> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-DCC-ZID-Univie-Metrics: mailbox 4242; Body=3 Fuz1=3 Fuz2=3 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 15 Apr 2002, Paul Saab wrote: > Lukas Ertl (l.ertl@univie.ac.at) wrote: > > Ok, I've listed my benchmark results at > > . > > I assume you let the parity initialize on the compaq? Yes, the RAID5 initialization was completed when I started the benchmarks. (And I used newfs defaults for both filesystems.) regards, le --=20 Lukas Ertl eMail: l.ertl@univie.ac.at UNIX-Systemadministrator Tel.: (+43 1) 4277-14073 Zentraler Informatikdienst (ZID) Fax.: (+43 1) 4277-9140 der Universit=E4t Wien http://mailbox.univie.ac.at/~le/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 15 14:41:36 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 3425637B416 for ; Mon, 15 Apr 2002 14:41:33 -0700 (PDT) Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id g3FLfQf63393 for ; Mon, 15 Apr 2002 14:41:28 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Mon, 15 Apr 2002 14:41:26 -0700 (PDT) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: scsi@freebsd.org Subject: is there a reason that da should *not* drive type STORAGE ARRAY Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Whilst dorking with an HP XP-512 storage arrage array on Fibre Channel, I found that it defaults to type STORAGE ARRAY (not DIRECT ACCESS). However, the DIRECT ACCESS commands work fine. Is there a reason why da(4) should *not* drive devices of type STORAGE ARRAY? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 15 14:45:41 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 7818337B400 for ; Mon, 15 Apr 2002 14:45:38 -0700 (PDT) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.6/8.11.5) with ESMTP id g3FLih983892; Mon, 15 Apr 2002 15:44:43 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Message-Id: <200204152144.g3FLih983892@aslan.scsiguy.com> To: mjacob@feral.com Cc: scsi@FreeBSD.ORG Subject: Re: is there a reason that da should *not* drive type STORAGE ARRAY In-Reply-To: Your message of "Mon, 15 Apr 2002 14:41:26 PDT." Date: Mon, 15 Apr 2002 15:44:43 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > >Whilst dorking with an HP XP-512 storage arrage array on Fibre Channel, I >found that it defaults to type STORAGE ARRAY (not DIRECT ACCESS). However, the >DIRECT ACCESS commands work fine. > >Is there a reason why da(4) should *not* drive devices of type STORAGE ARRAY? Fear of the unknown. What differentiates a STORAGE ARRAY from any other DIRECT ACCESS device? Is the assumption that they are essentially the same always valid? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 15 15: 3:40 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id B636D37B400 for ; Mon, 15 Apr 2002 15:03:37 -0700 (PDT) Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id g3FM3Zf63612; Mon, 15 Apr 2002 15:03:35 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Mon, 15 Apr 2002 15:03:35 -0700 (PDT) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: "Justin T. Gibbs" Cc: scsi@FreeBSD.ORG Subject: Re: is there a reason that da should *not* drive type STORAGE ARRAY In-Reply-To: <200204152144.g3FLih983892@aslan.scsiguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > > >Whilst dorking with an HP XP-512 storage arrage array on Fibre Channel, I > >found that it defaults to type STORAGE ARRAY (not DIRECT ACCESS). However, the > >DIRECT ACCESS commands work fine. > > > >Is there a reason why da(4) should *not* drive devices of type STORAGE ARRAY? > > Fear of the unknown. What differentiates a STORAGE ARRAY from any > other DIRECT ACCESS device? Is the assumption that they are essentially > the same always valid? Gee- I dunno. I've never really played with one. The spec (SCC2) is a bit ambiguous- it appears to support all the commands you'd want for a DIRECT ACCESS device (but does not explicitly list READ(6,10), WRITE(6,10) or FORMAT)- but also says: The model assumes all the SCSI peripheral devices controlled withuin a SCSI storage array are either fixed block or variable block devices. Considering that the only STORAGE ARRAY type devices I know of are disk devices, I'd say it's *moderately* safe to assume that da(4) should drive them. Let's say that it accrues better to FreeBSD to drive them out the door then mis-drive a device that nobody has seen yet ;-). -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 15 15:12:58 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 318EA37B404 for ; Mon, 15 Apr 2002 15:12:54 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g3FMCnq72143; Mon, 15 Apr 2002 16:12:49 -0600 (MDT) (envelope-from ken) Date: Mon, 15 Apr 2002 16:12:48 -0600 From: "Kenneth D. Merry" To: "Justin T. Gibbs" Cc: mjacob@feral.com, scsi@FreeBSD.ORG Subject: Re: is there a reason that da should *not* drive type STORAGE ARRAY Message-ID: <20020415161248.A72009@panzer.kdm.org> References: <200204152144.g3FLih983892@aslan.scsiguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200204152144.g3FLih983892@aslan.scsiguy.com>; from gibbs@scsiguy.com on Mon, Apr 15, 2002 at 03:44:43PM -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Apr 15, 2002 at 15:44:43 -0600, Justin T. Gibbs wrote: > > > >Whilst dorking with an HP XP-512 storage arrage array on Fibre Channel, I > >found that it defaults to type STORAGE ARRAY (not DIRECT ACCESS). However, the > >DIRECT ACCESS commands work fine. > > > >Is there a reason why da(4) should *not* drive devices of type STORAGE ARRAY? > > Fear of the unknown. What differentiates a STORAGE ARRAY from any > other DIRECT ACCESS device? Is the assumption that they are essentially > the same always valid? The da(4) driver doesn't attach to storage array (type 0xc) devices because they aren't supposed to be direct access type devices, at least in the generic case. If they're supposed to act like direct access devices, they should report inquiry data that indicates that, I think. This is from section 5.2.1.1 of the SCC-2 (rev 04) draft: ============= "All SCSI storage arrays shall accept LUN_Z as a valid address. For SCSI storage arrays LUN_Z shall be the logical unit that an application client addresses to configure an SCSI storage array and to determine information about the target and the logical units contained within the target. INQUIRY commands sent to LUN_Z shall return standard inquiry data with the SCCS bit set to one (See SCSI Primary Commands - 2). If the LUN_Z supports only the array controller commands defined within this standard, INQUIRY commands sent to LUN_Z shall return a device type of array controller device. Otherwise, INQUIRY commands sent to LUN_Z shall return a device type indicating the model defining the additional commands supported. Support for LUN_Z with a device type other than array controller device is vendor specific. The peripheral device address method shall be used when addressing the LUN_Z of an SCSI storage array (see 5.2.1.2.3)." ============= So it looks like it should be reporting a type of direct access, with the SCCS bit turned on. You might want to see whether there is some mode you can turn on in the controller to make it expose the arrays it manages. (Or have it tell the OS it is a direct access device instead of a storage array device.) Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 15 18:51:13 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 0380037B41E for ; Mon, 15 Apr 2002 18:50:13 -0700 (PDT) Received: from ledzep ([12.238.198.51]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020416015010.RRAK1083.rwcrmhc53.attbi.com@ledzep> for ; Tue, 16 Apr 2002 01:50:10 +0000 From: "Jordan Breeding" To: Subject: Trouble installing 5.0-DP1 to a Tyan Thunder K7 (aic7xxx)... Date: Tue, 16 Apr 2002 01:50:13 -0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000B_01C1E4E9.0D1509C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Disposition-Notification-To: "Jordan Breeding" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C1E4E9.0D1509C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, I have recently aquired a new Tyan Thunder K7 (S2462UNG) with on-board Adaptec scsi. Everything with the scsi works great in DOS, Linux and Windows. However, I hate using Windows, and Linux is giving me lots of trouble with this board in regards to rebooting and shuting down properly. I was playing with some old FreeBSD CDROMs I had laying around the other and it appeared that from the CDROM at least FreeBSD can correctly reboot this machine. While I still use linux for the bulk of my work I decided I could at least do a small install of FreeBSD on my virtually unused SCSI 4 GB hd at Channel A, id 0 and go from there. So I first decided to boot from the 5.0-DP1 iso which I downloaded, but this didn't work as I expected, the disc booted, found my IDE hard drive, found my SCSI CDROM and went into the sysinstal without ever finding my SCSI hard drive. So then I tried the 4.5 discs which I had laying around. I no longer have my 4.4 discs but something tells me those wouldn't have done much better, and I would want to be able to do CVS pulls of current anyway which was the original breakage I noticed. So since I do not have a serial console laying around at the moment I decided to do a boot -v and then boot the "live" filesystem and dump the dmesg to a floppy. In this email (sorry about the length) I have included a dmesg output from Linux (which works as far as the SCSI goes, I am using 2.4.19-pre6 with some other patches and am using the new aic7xxx driver from Justin Gibbs) as well as the dmesg from a boot -v showing the failure of the FreeBSD 5.0-DP1 boot to find my Channel A and hence failure to find my hard drive. Thanks for any help, please let me know if there is anything I can try to fix this. I do not have room anywhere on my current IDE drive for FreeBSD so I need to try and eventually get a fixed install method so that I can install to the scsi drive. Thanks for any help which you can give me in solving this situation. Jordan Breeding PS - I am not on this list so please Cc: me on replies. ------=_NextPart_000_000B_01C1E4E9.0D1509C0 Content-Type: text/plain; name="dmesg_linux.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg_linux.txt" IOS-e820: 000000001ffffc00 - 0000000020000000 (ACPI NVS) BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved) found SMP MP-table at 000f74d0 hm, page 000f7000 reserved twice. hm, page 000f8000 reserved twice. hm, page 0009f000 reserved twice. hm, page 000a0000 reserved twice. On node 0 totalpages: 131056 zone(0): 4096 pages. zone(1): 126960 pages. zone(2): 0 pages. ACPI: Searched entire block, no RSDP was found. ACPI: RSDP located at physical address c00f7470 RSD PTR v0 [PTLTD ] __va_range(0x1fffd505, 0x68): idx=3D8 mapped at ffff6000 ACPI table found: RSDT v1 [PTLTD RSDT 1540.0] __va_range(0x1ffffb2e, 0x24): idx=3D8 mapped at ffff6000 __va_range(0x1ffffb2e, 0x74): idx=3D8 mapped at ffff6000 ACPI table found: FACP v1 [TYAN GUINNESS 1540.0] __va_range(0x1ffffba2, 0x24): idx=3D8 mapped at ffff6000 __va_range(0x1ffffba2, 0x5e): idx=3D8 mapped at ffff6000 ACPI table found: APIC v1 [PTLTD APIC 1540.0] __va_range(0x1ffffba2, 0x5e): idx=3D8 mapped at ffff6000 LAPIC (acpi_id[0x0000] id[0x1] enabled[1]) CPU 0 (0x0100) enabledProcessor #1 Pentium(tm) Pro APIC version 16 LAPIC (acpi_id[0x0001] id[0x0] enabled[1]) CPU 1 (0x0000) enabledProcessor #0 Pentium(tm) Pro APIC version 16 IOAPIC (id[0x2] address[0xfec00000] global_irq_base[0x0]) INT_SRC_OVR (bus[0] irq[0x0] global_irq[0x2] polarity[0x1] trigger[0x1]) LAPIC_NMI (acpi_id[0x0000] polarity[0x1] trigger[0x1] lint[0x1]) LAPIC_NMI (acpi_id[0x0001] polarity[0x1] trigger[0x1] lint[0x1]) 2 CPUs total Local APIC address fee00000 Enabling the CPU's according to the ACPI table Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: TYAN Product ID: GUINNESS APIC at: 0xFEE00000 I/O APIC #2 Version 17 at 0xFEC00000. Processors: 2 Phoenix Technologies Ltd.Guinness-8 03/21/2002TyanTHUNDER K7EVT1 = 0123456789TyanTHUNDER K7EVT1 Kernel command line: ro = root=3D/dev/hda7 profile=3D2 nmi_watchdog=3D1 acpismp=3Dforce = video=3Dradeon:1280x1024-8@85 3 Initializing CPU#0 Detected 1592.916 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 3178.49 BogoMIPS Memory: 509716k/524224k available (2672k kernel code, 14120k reserved, = 645k data, 348k init, 0k highmem) Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) Mount-cache hash table entries: 8192 (order: 4, 65536 bytes) Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes) Page-cache hash table entries: 131072 (order: 7, 524288 bytes) CPU: Before vendor init, caps: 0383fbff c1cbfbff 00000000, vendor =3D 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After vendor init, caps: 0383fbff c1cbfbff 00000000 00000000 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After generic, caps: 0383fbff c1cbfbff 00000000 00000000 CPU: Common caps: 0383fbff c1cbfbff 00000000 00000000 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) mtrr: detected mtrr type: Intel CPU: Before vendor init, caps: 0383fbff c1cbfbff 00000000, vendor =3D 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After vendor init, caps: 0383fbff c1cbfbff 00000000 00000000 Intel machine check reporting enabled on CPU#0. CPU: After generic, caps: 0383fbff c1cbfbff 00000000 00000000 CPU: Common caps: 0383fbff c1cbfbff 00000000 00000000 CPU0: AMD Athlon(tm) MP 1900+ stepping 02 per-CPU timeslice cutoff: 731.57 usecs. enabled ExtINT on CPU#0 ESR value before enabling vector: 00000000 ESR value after enabling vector: 00000000 Booting processor 1/0 eip 2000 Initializing CPU#1 masked ExtINT on CPU#1 ESR value before enabling vector: 00000000 ESR value after enabling vector: 00000000 Calibrating delay loop... 3185.04 BogoMIPS CPU: Before vendor init, caps: 0383fbff c1cbfbff 00000000, vendor =3D 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After vendor init, caps: 0383fbff c1cbfbff 00000000 00000000 Intel machine check reporting enabled on CPU#1. CPU: After generic, caps: 0383fbff c1cbfbff 00000000 00000000 CPU: Common caps: 0383fbff c1cbfbff 00000000 00000000 CPU1: AMD Athlon(tm) Processor stepping 02 Total of 2 processors activated (6363.54 BogoMIPS). ENABLING IO-APIC IRQs Setting 2 in the phys_id_present_map ...changing IO-APIC physical APIC ID to 2 ... ok. init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-5, 2-7, 2-10, 2-11, 2-20, 2-21, 2-22, 2-23 = not connected. ..TIMER: vector=3D0x31 pin1=3D2 pin2=3D0 activating NMI Watchdog ... done. testing NMI watchdog ... CPU#0: NMI appears to be stuck! number of MP IRQ sources: 20. number of IO-APIC #2 registers: 24. testing the IO APIC....................... IO APIC #2...... .... register #00: 02000000 ....... : physical APIC id: 02 .... register #01: 00170011 ....... : max redirection entries: 0017 ....... : PRQ implemented: 0 ....... : IO APIC version: 0011 .... register #02: 00000000 ....... : arbitration: 00 .... IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: =20 00 000 00 1 0 0 0 0 0 0 00 01 003 03 0 0 0 0 0 1 1 39 02 003 03 0 0 0 0 0 1 1 31 03 003 03 0 0 0 0 0 1 1 41 04 003 03 0 0 0 0 0 1 1 49 05 000 00 1 0 0 0 0 0 0 00 06 003 03 0 0 0 0 0 1 1 51 07 000 00 1 0 0 0 0 0 0 00 08 003 03 0 0 0 0 0 1 1 59 09 003 03 0 0 0 0 0 1 1 61 0a 000 00 1 0 0 0 0 0 0 00 0b 000 00 1 0 0 0 0 0 0 00 0c 003 03 0 0 0 0 0 1 1 69 0d 003 03 0 0 0 0 0 1 1 71 0e 003 03 0 0 0 0 0 1 1 79 0f 003 03 0 0 0 0 0 1 1 81 10 003 03 1 1 0 1 0 1 1 89 11 003 03 1 1 0 1 0 1 1 91 12 003 03 1 1 0 1 0 1 1 99 13 003 03 1 1 0 1 0 1 1 A1 14 000 00 1 0 0 0 0 0 0 00 15 000 00 1 0 0 0 0 0 0 00 16 000 00 1 0 0 0 0 0 0 00 17 000 00 1 0 0 0 0 0 0 00 IRQ to pin mappings: IRQ0 -> 0:2 IRQ1 -> 0:1 IRQ3 -> 0:3 IRQ4 -> 0:4 IRQ6 -> 0:6 IRQ8 -> 0:8 IRQ9 -> 0:9 IRQ12 -> 0:12 IRQ13 -> 0:13 IRQ14 -> 0:14 IRQ15 -> 0:15 IRQ16 -> 0:16 IRQ17 -> 0:17 IRQ18 -> 0:18 IRQ19 -> 0:19 .................................... done. Using local APIC timer interrupts. calibrating APIC timer ... ..... CPU clock speed is 1592.9701 MHz. ..... host bus clock speed is 265.4950 MHz. cpu: 0, clocks: 2654950, slice: 884983 CPU0 cpu: 1, clocks: 2654950, slice: 884983 CPU1 checking TSC synchronization across CPUs: passed. Waiting on wait_init_idle (map =3D 0x2) All processors have done init_idle mtrr: your CPUs had inconsistent fixed MTRR settings mtrr: probably your BIOS does not setup all CPUs PCI: PCI BIOS revision 2.10 entry at 0xfd7c0, last bus=3D1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI->APIC IRQ transform: (B0,I7,P3) -> 19 PCI->APIC IRQ transform: (B0,I11,P0) -> 19 PCI->APIC IRQ transform: (B0,I12,P0) -> 16 PCI->APIC IRQ transform: (B0,I13,P0) -> 16 PCI->APIC IRQ transform: (B0,I13,P1) -> 17 PCI->APIC IRQ transform: (B0,I15,P0) -> 18 PCI->APIC IRQ transform: (B0,I16,P0) -> 19 PCI->APIC IRQ transform: (B1,I5,P0) -> 17 BIOS failed to enable PCI standards compliance, fixing this error. I/O APIC: AMD Errata #22 may be present. In the event of instability try : booting with the "noapic" option. isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd devfs: v1.12 (20020219) Richard Gooch (rgooch@atnf.csiro.au) devfs: boot_options: 0x1 Journalled Block Device driver loaded cdfs 0.5c loaded. NTFS driver v1.1.22 [Flags: R/W] Installing knfsd (copyright (C) 1996 okir@monad.swb.de). ACPI: Core Subsystem version [20011018] ACPI: Subsystem enabled ACPI: System firmware supports S0 S1 S4 S5 Processor[0]: C0 C1 Processor[1]: C0 C1 ACPI: Power Button (FF) found ACPI: Multiple power buttons detected, ignoring fixed-feature ACPI: Power Button (CM) found ACPI: Sleep Button (FF) found i2c-core.o: i2c core module version 2.6.3 (20020322) i2c-dev.o: i2c /dev entries driver module version 2.6.3 (20020322) i2c-proc.o version 2.6.3 (20020322) i2c-amd756.o version 2.6.3 (20020322) i2c-dev.o: Registered 'SMBus AMD7X6 adapter at 80e0' as minor 0 i2c-amd756.o: AMD756/766 bus detected and initialized i2c-isa.o version 2.6.3 (20020322) i2c-dev.o: Registered 'ISA main adapter' as minor 1 i2c-isa.o: ISA bus access for i2c modules initialized. radeonfb: ref_clk=3D2700, ref_div=3D12, xclk=3D23000 defaults Console: switching to colour frame buffer device 160x64 radeonfb: ATI Radeon 7500 QW DDR SGRAM 64 MB radeonfb: DVI port CRT monitor connected radeonfb: CRT port no monitor connected pty: 2048 Unix98 ptys configured w83781d.o version 2.6.3 (20020322) eeprom.o version 2.6.3 (20020322) Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ = SERIAL_PCI ISAPNP SERIAL_ACPI enabled ttyS00 at 0x03f8 (irq =3D 4) is a 16550A ttyS01 at 0x02f8 (irq =3D 3) is a 16550A ttyS04 at port 0x1400 (irq =3D 16) is a 16550A Real Time Clock Driver v1.10e Non-volatile memory driver v1.1 Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with = idebus=3Dxx AMD7411: IDE controller on PCI bus 00 dev 39 AMD7411: chipset revision 1 AMD7411: not 100% native mode: will probe irqs later AMD7411: disabling single-word DMA support (revision < C4) ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio hda: ST380021A, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=3D9729/255/63, = UDMA(100) Partition check: /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 < p5 p6 p7 p8 p9 p10 p11 p12 = p13 > Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html 00:0f.0: 3Com PCI 3c982 Dual Port Server Cyclone at 0x2000. Vers = LK1.1.16 00:10.0: 3Com PCI 3c982 Dual Port Server Cyclone at 0x2080. Vers = LK1.1.16 PPP generic driver version 2.4.2 PPP Deflate Compression module registered PPP BSD Compression module registered Universal TUN/TAP device driver 1.4 (C)1999-2001 Maxim Krasnyansky Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 439M agpgart: Detected AMD 760MP chipset agpgart: AGP aperture is 64M @ 0xec000000 [drm] AGP 0.99 on AMD Irongate @ 0xec000000 64MB [drm] Initialized radeon 1.1.1 20010405 on minor 0 SCSI subsystem driver Revision: 1.00 Loading Adaptec I2O RAID: Version 2.4 Build 5 Detecting Adaptec I2O RAID controllers... scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.5 aic7899: Ultra160 Wide Channel A, SCSI Id=3D7, 32/253 SCBs scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.5 aic7899: Ultra160 Wide Channel B, SCSI Id=3D7, 32/253 SCBs Vendor: IBM Model: DCAS-34330W Rev: S65A Type: Direct-Access ANSI SCSI revision: 02 (scsi0:A:0): 40.000MB/s transfers (20.000MHz, offset 15, 16bit) scsi0:A:0:0: Tagged Queuing enabled. Depth 253 Vendor: TEAC Model: CD-R55S Rev: 1.0R Type: CD-ROM ANSI SCSI revision: 02 Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 SCSI device sda: 8467200 512-byte hdwr sectors (4335 MB) /dev/scsi/host0/bus0/target0/lun0: p1 p2 Attached scsi CD-ROM sr0 at scsi1, channel 0, id 5, lun 0 (scsi1:A:5): 10.000MB/s transfers (10.000MHz, offset 15) sr0: scsi-1 drive Uniform CD-ROM driver Revision: 3.12 Creative EMU10K1 PCI Audio Driver, version 0.18, 17:24:28 Apr 11 2002 emu10k1: EMU10K1 rev 8 model 0x8027 found, IO at 0x2400-0x241f, IRQ 19 ac97_codec: AC97 codec, id: 0x5452:0x4123 (TriTech TR A5) usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-ohci.c: USB OHCI at membase 0xc00dc000, IRQ 19 usb-ohci.c: usb-00:07.4, Advanced Micro Devices [AMD] AMD-766 = [ViperPlus] USB usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 4 ports detected usb.c: registered new driver hiddev usb.c: registered new driver hid hid-core.c: v1.8 Andreas Gal, Vojtech Pavlik hid-core.c: USB HID support drivers mice: PS/2 mouse device common for all mice NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 2048 buckets, 32Kbytes TCP: Hash tables configured (established 16384 bind 21845) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. IPv6 v0.8 for NET4.0 IPv6 over IPv4 tunneling driver kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Mounted devfs on /dev Freeing unused kernel memory: 348k freed hub.c: USB new device connect on bus1/1, assigned device number 2 input0: USB HID v1.00 Mouse [0430:0100] on usb1:2.0 hub.c: USB new device connect on bus1/2, assigned device number 3 input1: USB HID v1.00 Keyboard [0430:0005] on usb1:3.0 Adding Swap: 2097136k swap-space (priority -1) Adding Swap: 2097136k swap-space (priority -2) EXT3 FS 2.4-0.9.17, 10 Jan 2002 on ide0(3,7), internal journal kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.17, 10 Jan 2002 on sd(8,1), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.17, 10 Jan 2002 on ide0(3,13), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.17, 10 Jan 2002 on ide0(3,12), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.17, 10 Jan 2002 on ide0(3,9), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.17, 10 Jan 2002 on ide0(3,1), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.17, 10 Jan 2002 on ide0(3,10), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.17, 10 Jan 2002 on ide0(3,8), internal journal EXT3-fs: mounted filesystem with ordered data mode. eth0: no IPv6 routers present eth1: no IPv6 routers present ------=_NextPart_000_000B_01C1E4E9.0D1509C0 Content-Type: text/plain; name="dmesg_freebsd.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg_freebsd.txt" Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-DP1 #1: Sun Apr 7 11:02:24 GMT 2002 murray@builder.freebsdmall.com:/usr/src/sys/i386/compile/BOOTMFS Preloaded elf kernel "/kernel" at 0xc0815000. Preloaded mfs_root "/mfsroot" at 0xc0815090. Calibrating clock(s) ... TSC clock: 1592628231 Hz, i8254 clock: 1192980 = Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter "TSC" frequency 1592902403 Hz CPU: AMD Athlon(tm) MP 1900+ (1592.90-MHz 686-class CPU) Origin =3D "AuthenticAMD" Id =3D 0x662 Stepping =3D 2 = Features=3D0x383fbff AMD Features=3D0xc0480000 Data TLB: 32 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way = associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way = associative real memory =3D 536805376 (524224K bytes) Physical memory chunk(s): 0x00001000 - 0x0009dfff, 643072 bytes (157 pages) 0x0083c000 - 0x1ffe7fff, 528138240 bytes (128940 pages) avail memory =3D 514035712 (501988K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f7440 bios32: Entry =3D 0xfd6a0 (c00fd6a0) Rev =3D 0 Len =3D 1 pcibios: PCI BIOS entry at 0xfd6a0+0x120 pnpbios: Found PnP BIOS data at 0xc00f7490 pnpbios: Entry =3D f0000:9ea4 Rev =3D 1.0 Other BIOS signatures found: null: mem: Pentium Pro MTRR support enabled md0: Preloaded image 4423680 bytes at 0xc03dbf00 Creating DISK md0 pci_open(1): mode 1 addr port (0x0cf8) is 0x80003850 pci_open(1a): mode1res=3D0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=3D060000] [hdr=3D00] is there = (id=3D700c1022) Using $PIR table, 268435454 entries at 0xc00fdef0 npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: physical bus=3D0 map[10]: type 3, range 32, base ec000000, size 26, enabled map[14]: type 3, range 32, base e8004000, size 12, enabled map[18]: type 4, range 32, base 00002430, size 2, port disabled found-> vendor=3D0x1022, dev=3D0x700c, revid=3D0x11 bus=3D0, slot=3D0, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 found-> vendor=3D0x1022, dev=3D0x700d, revid=3D0x00 bus=3D0, slot=3D1, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 found-> vendor=3D0x1022, dev=3D0x7410, revid=3D0x02 bus=3D0, slot=3D7, func=3D0 class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 map[20]: type 4, range 32, base 0000f000, size 4, enabled found-> vendor=3D0x1022, dev=3D0x7411, revid=3D0x01 bus=3D0, slot=3D7, func=3D1 class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D0 found-> vendor=3D0x1022, dev=3D0x7413, revid=3D0x01 bus=3D0, slot=3D7, func=3D3 class=3D06-80-00, hdrtype=3D0x00, mfdev=3D0 map[10]: type 1, range 32, base 000dc000, size 12, enabled found-> vendor=3D0x1022, dev=3D0x7414, revid=3D0x07 bus=3D0, slot=3D7, func=3D4 class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D0 intpin=3Dd, irq=3D11 map[10]: type 4, range 32, base 00002400, size 5, enabled found-> vendor=3D0x1102, dev=3D0x0002, revid=3D0x08 bus=3D0, slot=3D11, func=3D0 class=3D04-01-00, hdrtype=3D0x00, mfdev=3D1 intpin=3Da, irq=3D11 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 00002438, size 3, enabled found-> vendor=3D0x1102, dev=3D0x7002, revid=3D0x08 bus=3D0, slot=3D11, func=3D1 class=3D09-80-00, hdrtype=3D0x00, mfdev=3D1 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base e8003000, size 8, enabled map[14]: type 4, range 32, base 00001400, size 8, enabled map[18]: type 4, range 32, base 00001000, size 8, enabled map[1c]: type 4, range 32, base 00002440, size 3, enabled found-> vendor=3D0x11c1, dev=3D0x0480, revid=3D0x00 bus=3D0, slot=3D12, func=3D0 class=3D07-03-03, hdrtype=3D0x00, mfdev=3D0 intpin=3Da, irq=3D5 powerspec 2 supports D0 D2 D3 current D0 map[10]: type 4, range 32, base 00001800, size 8, enabled map[14]: type 1, range 64, base e8001000, size 12, enabled found-> vendor=3D0x9005, dev=3D0x00cf, revid=3D0x01 bus=3D0, slot=3D13, func=3D0 class=3D01-00-00, hdrtype=3D0x00, mfdev=3D1 intpin=3Da, irq=3D5 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00001c00, size 8, enabled map[14]: type 1, range 64, base e8002000, size 12, enabled found-> vendor=3D0x9005, dev=3D0x00cf, revid=3D0x01 bus=3D0, slot=3D13, func=3D1 class=3D01-00-00, hdrtype=3D0x00, mfdev=3D1 intpin=3Db, irq=3D10 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00002000, size 7, enabled map[14]: type 1, range 32, base e8003400, size 7, enabled found-> vendor=3D0x10b7, dev=3D0x9805, revid=3D0x78 bus=3D0, slot=3D15, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 intpin=3Da, irq=3D7 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 00002080, size 7, enabled map[14]: type 1, range 32, base e8003800, size 7, enabled found-> vendor=3D0x10b7, dev=3D0x9805, revid=3D0x78 bus=3D0, slot=3D16, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 intpin=3Da, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x3000-0x3fff pcib1: memory decode 0xe8100000-0xe81fffff pcib1: prefetched decode 0xf0000000-0xf7ffffff pci1: physical bus=3D1 map[10]: type 3, range 32, base f0000000, size 27, enabled map[14]: type 4, range 32, base 00003000, size 8, enabled map[18]: type 1, range 32, base e8100000, size 16, enabled found-> vendor=3D0x1002, dev=3D0x5157, revid=3D0x00 bus=3D1, slot=3D5, func=3D0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 intpin=3Da, irq=3D255 powerspec 2 supports D0 D1 D2 D3 current D0 pci1: on pcib1 pci1: at device 5.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on = pci0 ata0: iobase=3D0x01f0 altiobase=3D0x03f6 bmaddr=3D0xf000 ata0: mask=3D03 ostat0=3D50 ostat2=3D00 ata0-master: ATAPI 00 00 ata0-slave: ATAPI 00 00 ata0: mask=3D03 stat0=3D50 stat1=3D00 ata0-master: ATA 01 a5 ata0: devices=3D01 ata0: at 0x1f0 irq 14 on atapci0 ata1: iobase=3D0x0170 altiobase=3D0x0376 bmaddr=3D0xf008 ata1: mask=3D03 ostat0=3D20 ostat2=3D30 ata1-master: ATAPI 20 20 ata1-slave: ATAPI 30 30 ata1: mask=3D03 stat0=3D20 stat1=3D30 ata1-master: ATA 25 25 ata1-slave: ATA 25 25 ata1: devices=3D00 ata1: at 0x170 irq 15 on atapci0 pci0: at device 7.3 (no driver attached) ohci0: mem 0xdc000-0xdcfff irq 11 at device 7.4 = on pci0 usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered ums0: Sun Microsystems Type 6 USB mouse, rev 1.00/1.02, addr 2, iclass = 3/1 ums0: 3 buttons ukbd0: Sun Microsystems Type 6 USB keyboard, rev 1.00/1.02, addr 3, = iclass 3/1 kbd: new array size 4 kbd1 at ukbd0 kbd1: ukbd0, generic (0), config:0x0, flags:0x1d0000 pci0: at device 11.0 (no driver attached) pci0: