From owner-freebsd-scsi Sun Apr 27 06:18:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA11233 for freebsd-scsi-outgoing; Sun, 27 Apr 1997 06:18:15 -0700 (PDT) Received: from zeta.wexler.co.il (zeta.wexler.co.il [192.115.233.222]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA11227 for ; Sun, 27 Apr 1997 06:18:01 -0700 (PDT) Received: from zeta.wexler.co.il.wexler.co.il (alpha.wexler.co.il [192.115.233.193]) by zeta.wexler.co.il (8.8.5/8.8.5) with SMTP id QAA10069 for ; Sun, 27 Apr 1997 16:20:55 +0300 (IDT) Message-Id: <199704271320.QAA10069@zeta.wexler.co.il> Comments: Authenticated sender is From: "Enoch Wexler" To: freebsd-scsi@freebsd.org Date: Sun, 27 Apr 1997 16:17:02 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Buslogic 948 Priority: normal X-mailer: Pegasus Mail for Win32 (v2.53/R1) Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Good day to you, What is the latest info on BT-948 compatibity with FreeBSD? Is it similar enough to the approved 946C? We will receive in a few days this card ;though ordered Adaptec 2940U ;Mail order shops... :-( Thank you, Enoch Wexler. From owner-freebsd-scsi Tue Apr 29 09:22:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA23689 for freebsd-scsi-outgoing; Tue, 29 Apr 1997 09:22:05 -0700 (PDT) Received: from dn800e0.fingerhut.com (dn800e0-ext.fingerhut.com [204.221.45.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA23678 for ; Tue, 29 Apr 1997 09:21:57 -0700 (PDT) Received: from dn800e0.fingerhut.com (root@localhost) by dn800e0.fingerhut.com (8.7.5/8.7.3) with ESMTP id LAA29889 for ; Tue, 29 Apr 1997 11:23:27 -0500 (CDT) Received: from seag.fingerhut.com (GF007E0.SEAG.fingerhut.com [151.210.140.7]) by dn800e0.fingerhut.com (8.7.5/8.7.3) with SMTP id LAA29885 for ; Tue, 29 Apr 1997 11:23:26 -0500 (CDT) Received: from gf006e0.seag.fingerhut.com by seag.fingerhut.com (SMI-8.6/SMI-SVR4) id LAA06995; Tue, 29 Apr 1997 11:21:53 -0500 Received: by gf006e0.seag.fingerhut.com (5.x/SMI-SVR4) id AA09568; Tue, 29 Apr 1997 11:21:48 -0500 Date: Tue, 29 Apr 1997 11:21:48 -0500 Message-Id: <9704291621.AA09568@gf006e0.seag.fingerhut.com> From: Bruce Albrecht To: freebsd-scsi@freebsd.org Subject: Can find changer for Compaq autoloader (4586NP) Mime-Version: 1.0 (generated by tm-edit 7.68) Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm trying to set up my Compaq autoloader (Seagate 4586NP based) in -current (from 4/27), and it can't seem to find the changer when booting. It could find it on a NetBSD system (although I never actually got it to work, because the controller was SCSI-1), and it shows up in the list of devices when the NCR bios scans the devices. I've got two NCR controllers (810 and 875 based), the autoloader is on the 810. My kernel has the ch0 device defined, there's a /dev/ch0, and I've even tried to hardwire the cho device in the kernel, without success. Is there something I'm missing? Where should I go from here? From owner-freebsd-scsi Tue Apr 29 13:21:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA07916 for freebsd-scsi-outgoing; Tue, 29 Apr 1997 13:21:03 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA07902 for ; Tue, 29 Apr 1997 13:20:55 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA29941; Tue, 29 Apr 1997 22:20:36 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id WAA05186; Tue, 29 Apr 1997 22:13:48 +0200 (MET DST) Message-ID: <19970429221348.HH39341@uriah.heep.sax.de> Date: Tue, 29 Apr 1997 22:13:48 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-scsi@freebsd.org Cc: Bruce.Albrecht@seag.fingerhut.com (Bruce Albrecht) Subject: Re: Can find changer for Compaq autoloader (4586NP) References: <9704291621.AA09568@gf006e0.seag.fingerhut.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <9704291621.AA09568@gf006e0.seag.fingerhut.com>; from Bruce Albrecht on Apr 29, 1997 11:21:48 -0500 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Bruce Albrecht wrote: > Is there something I'm missing? Where should I go from here? Post the changer-related boot messages from a boot -v. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Wed Apr 30 06:43:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA26682 for freebsd-scsi-outgoing; Wed, 30 Apr 1997 06:43:11 -0700 (PDT) Received: from weenix.guru.org (kmitch@phantasma.bevc.blacksburg.va.us [198.82.200.65]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA26677 for ; Wed, 30 Apr 1997 06:43:08 -0700 (PDT) Received: (from kmitch@localhost) by weenix.guru.org (8.8.5/8.8.5) id JAA27473 for scsi@freebsd.org; Wed, 30 Apr 1997 09:43:05 -0400 (EDT) From: Keith Mitchell Message-Id: <199704301343.JAA27473@weenix.guru.org> Subject: SCB Paging & 3940UW To: scsi@freebsd.org Date: Wed, 30 Apr 1997 09:43:05 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am getting a few SCB paging errors during my nightly backup. They occur on my DAT drive (Archive Python DDS-2). The system does seem to recover from it though. I am running -current from 4/29. I am only running with SCB Paging (no tagged queueing). The errors are: st0: SCB 0x1 - timed out in command phase, SCSISIGI == 0x84 SEQADDR = 0x4f SCSISEQ = 0x12 SSTAT0 = 0x7 SSTAT1 = 0x2 st0: abort message in message buffer st0: SCB 0x1 - timed out in command phase, SCSISIGI == 0x94 SEQADDR = 0x4f SCSISEQ = 0x12 SSTAT0 = 0x7 SSTAT1 = 0x2 ahc0: Issued Channel A Bus Reset. 3 SCBs aborted Clearing bus reset Clearing 'in-reset' flag st0: Target Busy st0: Target Busy st0: Target Busy st0: Target Busy st0: Target Busy st0: Target Busy st0: Target Busy st0: Target Busy st0: Target Busy st0: Target Busy st0: Target Busy st0: Target Busy -- Keith Mitchell Head Administrator: acm.vt.edu Email: kmitch@weenix.guru.org PGP key available upon request http://weenix.guru.org/~kmitch Address and URL (c) 1997 Keith Mitchell - All Rights Reserved Unauthorized use or duplication prohibited From owner-freebsd-scsi Wed Apr 30 18:23:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA26647 for freebsd-scsi-outgoing; Wed, 30 Apr 1997 18:23:13 -0700 (PDT) Received: from trifork.gu.net (trifork.gu.net [194.93.190.194]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA26634; Wed, 30 Apr 1997 18:23:00 -0700 (PDT) Received: from localhost (localhost.gu.kiev.ua [127.0.0.1]) by trifork.gu.net (8.8.5/8.8.5) with SMTP id EAA00873; Thu, 1 May 1997 04:23:07 +0300 (EEST) Date: Thu, 1 May 1997 04:23:07 +0300 (EEST) From: Andrew Stesin Reply-To: stesin@gu.net To: dg@root.com, se@freebsd.org, Michael Smith cc: hackers@freebsd.org, scsi@freebsd.org Subject: Intel XXpress - partial success! (was: 2 PCI busses, 2 AIC chips... In-Reply-To: <199704090022.JAA21738@genesis.atrad.adelaide.edu.au> Message-ID: X-NCC-RegID: ua.gu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, that's me again and it seems to me that the XXpress saga will come to the end soon -- with FreeBSD final victory, I hope :) This machine is going to become a mail relay of major importance. For several reasons, commercial unices aren't an option. The machine is Big and Nice ;) but only Solaris x86 was able to live successfully on it -- more or less, because neither Linux nor Solaris were able to recognize _both_ AIC7870 chips, only the first one worked. Ok, first time FreeBSD failed to sit on it and live there; and my collegues are all Linux-oriented men, they put some fancy Linux distribution onto this box, with 2.0.30 kernel. Test run: a loaded Squid proxy caused a silent crash of Linux, no reboot, nothing, just death with a one-line panic message, after 1-2 days of uptime. Other Linux kernels -- same behaviour. So now I got the box again, and -- cool! patch by David Greenman succeeded, thanks! The first and the most boring problem is solved, 2 AIC chips are recognized. Dear Stefan, wouldn't you mind commiting a cleaner equivalent of the pci.c fix below to both code branches, please. Some questions still remain, though. I.e.: what are those PCI chips, they are unknown to FreeBSD, they caused weirdness in the dmesg output below? Why on the Earth I'm seeing that infamous-since-i386-days "stray irq 7" message once again? What does the message: "ahc0: Reading SEEPROM...checksum error", "ahc0: No SEEPROM available" mean -- is this Ok? (And will FreeBSD on this machine more stable than the "other OS" was? ;) On Wed, 9 Apr 1997, Michael Smith wrote: > > 4. XPC 637909-001 (no idea) > > 5. XPD 637910-001 2 parts (no idea) > > Um, they sound a lot like FPGA or some other gate array parts. Do they > have logos on them? Yes, Intel logos as well. I also noticed some references to a string XPC in the BIOS setup, somewhere under "Advanced -> ... chipset ..." screen. I have no ideas what can this mean... BIOS is AMI, version is 1.00.06.BG0 "Interesting" options are: Force BSP to slot 2 [Disable] Force XPC Posted Write [Auto Detect] ... Current XPC Posted Write ??? > Stick a serial cable on com1 leading to another machine, and use the > '-hv' boot flags to get it to use the serial console. Attempts to do so brought an unusual effect (BTW: BIOS is capable to redirect it's output to the serial console), GENERIC kernel started writing to serial port but as soon as it detected video & keyboard it started writing all the rest there... :) > > I'm considering this, but I don't trust my own skills of > > hacking pretty unfamiliar kernel code to get production > > system running in 2-3 days... I still hope that there already is > > a solution... > > 2-3 days on a new platform? Is this your timeframe or your customer's? > Whoever, they gotta be _nuts_! No. This system is for us -- and it _should_ be ready 2 weeks ago to start a "test run", with some simple functions like web proxy running there, while the rest details of the configuration are being done. Best regards, Andrew Stesin nic-hdl: ST73-RIPE ---------- fix to pci.c --------- 8< -------------------------------- *** pci.c-releng22 Thu May 1 00:20:48 1997 --- pci.c Thu May 1 00:21:54 1997 *************** *** 152,161 **** --- 152,180 ---- static int pci_conf_count; static int pci_info_done; static int pcibusmax; static struct pcicb *pcicb; + /*-------------------------------------------------------- + ** + ** DG's patch to deal with a crazy Intel XXpress: + ** it has 2 PCI busses, both are primary (?) + ** + **-------------------------------------------------------- + */ + #define SECOND_BUS 1 + static struct pcicb pcibus1 = { + NULL, NULL, NULL, + { 0 }, + 0, SECOND_BUS, 0, 0, + 0, 0, 0, 0, 0, 0, 0, 0, /* real allocation */ + 0, 0xFFFF, /* iobase/limit */ + 0x2000000, 0xFFFFFFFFu, /* nonprefetch membase/limit */ + 0x2000000, 0xFFFFFFFFu /* prefetch membase/limit */ + }; + + /*----------------------------------------------------------------- ** ** The following functions are provided for the device driver ** to read/write the configuration space. ** *************** *** 891,900 **** --- 910,942 ---- if (pcicb) pcicb = pcicb->pcicb_next; } pcibusmax++; } + #ifdef SECOND_BUS + /*-------------------------------------------------------- + ** + ** DG's patch to deal with a crazy Intel XXpress: + ** it has 2 PCI busses, both are primary (?) + ** + **-------------------------------------------------------- + */ + for (pcicb = &pcibus1; pcicb != NULL;) { + pci_bus_config (); + + if (pcicb->pcicb_down) { + pcicb = pcicb->pcicb_down; + continue; + }; + + while (pcicb && !pcicb->pcicb_next) + pcicb = pcicb->pcicb_up; + + if (pcicb) + pcicb = pcicb->pcicb_next; + } + #endif pci_conf_count++; } /*----------------------------------------------------------------------- ** ----------- XXpress' dmesg output after verbose boot --- 8< --------------- Copyright (c) 1992-1996 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 2.2-970427-RELENG #1: Thu May 1 00:24:37 GMT 1997 root@whitestar.gu.net:/usr/src/sys/compile/XXPRESS Calibrating clock(s) ... i586 clock: 166669373 Hz, i8254 clock: 1193166 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency CLK_USE_I586_CALIBRATION not specified - using old calibration method CPU: Pentium (160.01-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping=12 Features=0x3bf real memory = 167772160 (163840K bytes) avail memory = 162467840 (158660K bytes) eisa0: Probing for devices on the EISA bus ep0: <3Com 3C579-BNC EISA Network Adapter> at 0x2000-0x200f, 0x2c80-0x2c89 irq 5 ep0: on eisa0 slot 2 ep0: aui/bnc[*BNC*] address 00:20:af:53:1e:22 pcibus_setup(1): mode 1 addr port (0x0cf8) is 0x80007804 pcibus_setup(1a): mode1res=0x80000000 (0x80000000) pcibus_check: device 0 is there (id=12258086) Probing for devices on PCI bus 0: configuration mode 1 allows 32 devices. chip0 rev 2 on pci0:0 chip1 rev 5 on pci0:14:0 pci0:15:0: Intel Corporation, device=0x0008, class=0xff, subclass=0x00 [no driver assigned] map(10): mem32(ffe7fc08) map(14): mem32(ffe7fc08) map(18): mem32(ffe7fc08) map(1c): mem32(ffe7fc08) map(20): mem32(ffe7fc08) map(24): mem32(ffe7fc08) pci0:15:1: Intel Corporation, device=0x0008, class=0xff, subclass=0x00 [no driver assigned] map(10): mem32(ffe7fc08) map(14): mem32(ffe7fc08) map(18): mem32(ffe7fc08) map(1c): mem32(ffe7fc08) map(20): mem32(ffe7fc08) map(24): mem32(ffe7fc08) pci0:15:2: Intel Corporation, device=0x0008, class=0xff, subclass=0x00 [no driver assigned] map(10): mem32(ffe7fc08) map(14): mem32(ffe7fc08) map(18): mem32(ffe7fc08) map(1c): mem32(ffe7fc08) map(20): mem32(ffe7fc08) map(24): mem32(ffe7fc08) pci0:15:3: Intel Corporation, device=0x0008, class=0xff, subclass=0x00 [no driver assigned] map(10): mem32(ffe7fc08) map(14): mem32(ffe7fc08) map(18): mem32(ffe7fc08) map(1c): mem32(ffe7fc08) map(20): mem32(ffe7fc08) map(24): mem32(ffe7fc08) pci0:15:4: Intel Corporation, device=0x0008, class=0xff, subclass=0x00 [no driver assigned] map(10): mem32(ffe7fc08) map(14): mem32(ffe7fc08) map(18): mem32(ffe7fc08) map(1c): mem32(ffe7fc08) map(20): mem32(ffe7fc08) map(24): mem32(ffe7fc08) pci0:15:5: Intel Corporation, device=0x0008, class=0xff, subclass=0x00 [no driver assigned] map(10): mem32(ffe7fc08) map(14): mem32(ffe7fc08) map(18): mem32(ffe7fc08) map(1c): mem32(ffe7fc08) map(20): mem32(ffe7fc08) map(24): mem32(ffe7fc08) pci0:15:6: Intel Corporation, device=0x0008, class=0xff, subclass=0x00 [no driver assigned] map(10): mem32(ffe7fc08) map(14): mem32(ffe7fc08) map(18): mem32(ffe7fc08) map(1c): mem32(ffe7fc08) map(20): mem32(ffe7fc08) map(24): mem32(ffe7fc08) pci0:15:7: Intel Corporation, device=0x0008, class=0xff, subclass=0x00 [no driver assigned] map(10): mem32(ffe7fc08) map(14): mem32(ffe7fc08) map(18): mem32(ffe7fc08) map(1c): mem32(ffe7fc08) map(20): mem32(ffe7fc08) map(24): mem32(ffe7fc08) Probing for devices on PCI bus 1: chip2 rev 2 on pci1:0 ahc0 rev 3 int a irq 10 on pci1:13 mapreg[10] type=1 addr=0000fc00 size=0100. mapreg[14] type=0 addr=ffcff000 size=1000. reg20: virtual=0xf6963000 physical=0xffcff000 size=0x1000 ahc0: Reading SEEPROM...checksum error ahc0: No SEEPROM available ahc0: Using left over BIOS settings ahc0: aic7870 Wide Channel, SCSI Id=7, 16/255 SCBs ahc0: Resetting Channel A ahc0: Downloading Sequencer Program...ahc0: 411 instructions downloaded Done ahc0: Probing channel A ahc0 waiting for scsi devices to settle ahc0: target 1 using 16Bit transfers ahc0: target 1 synchronous at 10.0MHz, offset = 0x8 ahc0: target 1 Tagged Queuing Device (ahc0:1:0): "SEAGATE ST34371W 0484" type 0 fixed SCSI 2 sd0(ahc0:1:0): Direct-Access 4148MB (8496884 512 byte sectors) sd0(ahc0:1:0): with 5172 cyls, 10 heads, and an average 164 sectors/track ahc1 rev 3 int a irq 9 on pci1:14 mapreg[10] type=1 addr=0000f800 size=0100. mapreg[14] type=0 addr=ffcfe000 size=1000. reg20: virtual=0xf6966000 physical=0xffcfe000 size=0x1000 ahc1: Reading SEEPROM...checksum error ahc1: No SEEPROM available ahc1: aic7870 Wide Channel, SCSI Id=7, 16/255 SCBs ahc1: Resetting Channel A ahc1: Host Adapter Bios disabled. Using default SCSI device parameters ahc1: Downloading Sequencer Program...ahc1: 411 instructions downloaded Done ahc1: Probing channel A ahc1 waiting for scsi devices to settle ahc1: target 6 using 16Bit transfers ahc1: target 6 synchronous at 10.0MHz, offset = 0x8 ahc1: target 6 Tagged Queuing Device (ahc1:6:0): "SEAGATE ST34371W 0484" type 0 fixed SCSI 2 sd1(ahc1:6:0): Direct-Access 4148MB (8496884 512 byte sectors) sd1(ahc1:6:0): with 5172 cyls, 10 heads, and an average 164 sectors/track pci1: uses 8192 bytes of memory from ffcfe000 upto ffcfffff. pci1: uses 512 bytes of I/O space from f800 upto fcff. Probing for devices on the ISA bus: sc0: the current keyboard controller command byte 0065 kbdio: RESET_KBD return code:00fa kbdio: RESET_KBD status:00aa sc0 at 0x60-0x6f irq 1 on motherboard sc0: BIOS video mode:3 sc0: VGA registers upon power-up 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 ff ff 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff sc0: video mode:24 sc0: VGA registers for mode:24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 not found at 0x2f8 lpt0 not found at 0xffffffff psm0: current command byte:0065 kbdio: TEST_AUX_PORT status:0000 kbdio: RESET_AUX return code:00fa kbdio: RESET_AUX status:00aa kbdio: RESET_AUX ID:0000 psm0: status after reset 00 02 64 psm: status 00 00 64 (get_mouse_buttons) psm0: status 00 02 64 psm0 at 0x60-0x64 irq 12 on motherboard psm0: device ID 0, 2 buttons fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 flags 0x80ff80ff on isa wdc0: unit 0 (wd0): , multi-block-16 wd0: 1032MB (2113776 sectors), 2097 cyls, 16 heads, 63 S/T, 512 B/S ep0 not found at 0x300 npx0 flags 0x1 on motherboard npx0: INT 16 interface imasks: bio c0004640, tty c0031032, net c0031032 BIOS Geometries: 0:020a3f3f 0..522=523 cylinders, 0..63=64 heads, 1..63=63 sectors 0 accounted for Device configuration finished. Considering FFS root f/s. configure() finished. new masks: bio c0004640, tty c0031032, net c0031032 wd0s1: type 0xa5, start 0, end = 2113775, size 2113776 wd0s1: C/H/S end 131/146/63 (1222451) != end 2113775: invalid stray irq 7 From owner-freebsd-scsi Thu May 1 08:57:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA00319 for freebsd-scsi-outgoing; Thu, 1 May 1997 08:57:38 -0700 (PDT) Received: from tor-adm1.nbc.netcom.ca (taob@tor-adm1.nbc.netcom.ca [207.181.89.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA00314 for ; Thu, 1 May 1997 08:57:36 -0700 (PDT) Received: from localhost (taob@localhost) by tor-adm1.nbc.netcom.ca (8.8.5/8.8.5) with SMTP id LAA01326 for ; Thu, 1 May 1997 11:56:29 -0400 (EDT) Date: Thu, 1 May 1997 11:56:28 -0400 (EDT) From: Brian Tao To: FREEBSD-SCSI Subject: Anyone use a SyJet 1.5GB cartridge drive? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm thinking of picking up a Syquest SyJet removeable drive and a few 1.5GB carts to go with it. They have an external SCSI-2 version that looks like it should work under FreeBSD, but I wanted to see if anyone else has successfully used a SyJet drive. I don't need it as a boot device, just to keep FreeBSD install distributions and the like. -- Brian Tao (BT300, taob@netcom.ca) "Though this be madness, yet there is method in't" From owner-freebsd-scsi Thu May 1 14:19:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA17883 for freebsd-scsi-outgoing; Thu, 1 May 1997 14:19:23 -0700 (PDT) Received: from pluto.plutotech.com (root@pluto100.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA17860; Thu, 1 May 1997 14:19:11 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.3) with ESMTP id PAA20788; Thu, 1 May 1997 15:19:06 -0600 (MDT) Message-Id: <199705012119.PAA20788@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Bruce Evans , sos@freefall.FreeBSD.ORG cc: freeBSD-arch@FreeBSD.org, freeBSD-scsi@FreeBSD.org Subject: Re: cvs commit: src/sys/scsi sd.c In-reply-to: Your message of "Fri, 02 May 1997 06:23:21 +1000." <199705012023.GAA24197@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 May 1997 16:17:24 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Moved to FreeBSD-scsi and FreeBSD-arch which are more appropriate. >The != 512byte sector support breaks at least EOF handling. (dscheck() >rewrites both bp-b_resid and bp->b_bcount for transfers that cross the >end of the partition, but the != 512byte sector support does extra work >to prevent the change to bp->b_bcount. I think it does this prevent >truncation giving a count that isn't a multiple of sec_blk_ratio. I think >the count is always a multiple except for misconfigured partitions. >Partition sizes currently need to be multiples of sec_blk_ratio to >prevent this. Partition sizes should really be in units of sectors.) > >Bruce We need to really think about how we want to handle media with block sizes greater than DEV_BSIZE. Some questions to answer are: 1) What should sd and other devices drivers "see" by the time they receive the I/O? Should b_blkno always be in terms of the logical block size of the device or should the device driver be responsible for scaling? I personally don't like the fact that every device driver has to do this conversion. Code duplication is error prone. 2) If we decide that it really should be in terms of the logical block size of the device, what consequences does this have on information in the disklabel and how it's used by other areas of the kernel? 3) What features do we want to support? Do we want to support the ability to 'dd' an image from a 512byte sectored device to a 1k sectored device and have it work? If so, what constraints are needed? (disklabel has the larger block size even on the smaller sector sized disk? or is it just that your frag and fs block sizes need to be in sync?) 4) If we want to have partitions with the only constraint being that they begin and end on a sector boundary, what else in the system needs to change to allow this? How does this affect 2 and 3? -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Thu May 1 15:31:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA21705 for freebsd-scsi-outgoing; Thu, 1 May 1997 15:31:55 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA21674; Thu, 1 May 1997 15:30:53 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id IAA29072; Fri, 2 May 1997 08:28:01 +1000 Date: Fri, 2 May 1997 08:28:01 +1000 From: Bruce Evans Message-Id: <199705012228.IAA29072@godzilla.zeta.org.au> To: bde@zeta.org.au, gibbs@plutotech.com, sos@freefall.freebsd.org Subject: Re: cvs commit: src/sys/scsi sd.c Cc: freeBSD-arch@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >We need to really think about how we want to handle media with block >sizes greater than DEV_BSIZE. Some questions to answer are: disklabel.h says that the sizes in the label are in "sectors", and I think it is best to use physical sectors in labels and in-core slice tables. >1) What should sd and other devices drivers "see" by the time they receive >the I/O? Should b_blkno always be in terms of the logical block size of >the device or should the device driver be responsible for scaling? Note that b_blkno is normally not used after dscheck(). dscheck() does conversions as well as checks, leaving the final block number in b_pblkno. It's probably best for b_blkno to always be in DEV_BSIZE units and b_pblkno to be in terms of the physical block size. This seems to be the case in sd.c now. b_blkno is scaled to physical units so dscheck() returns b_pblkno in physical units. b_blkno is scaled back to logical units and b_pblkno is sent to the controller. I think b_blkno is only used again if there is an error (diskerr() uses it). >2) If we decide that it really should be in terms of the logical block size >of the device, what consequences does this have on information in the >disklabel and how it's used by other areas of the kernel? No consequences, I hope. The kernel can continue to use 512-byte blocks except in labeling code and drivers. >3) What features do we want to support? Do we want to support the ability >to 'dd' an image from a 512byte sectored device to a 1k sectored device >and have it work? If so, what constraints are needed? (disklabel has >the larger block size even on the smaller sector sized disk? or is it just >that your frag and fs block sizes need to be in sync?) I think that this is too hard to be worth supporting. It can't work in general, because the source partitions might have a size that is not a multiple of the target block size. >4) If we want to have partitions with the only constraint being that they >begin and end on a sector boundary, what else in the system needs to change >to allow this? How does this affect 2 and 3? You also need to constrain file system fragment sizes to a multiple of the sector size for a simple implementation. I think only sizes of 512, 1024, 2048 and 4096 are practical. Bruce From owner-freebsd-scsi Thu May 1 16:13:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA24189 for freebsd-scsi-outgoing; Thu, 1 May 1997 16:13:53 -0700 (PDT) Received: from pluto.plutotech.com (root@pluto100.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA24166; Thu, 1 May 1997 16:13:38 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.3) with ESMTP id RAA24125; Thu, 1 May 1997 17:13:03 -0600 (MDT) Message-Id: <199705012313.RAA24125@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Bruce Evans cc: gibbs@plutotech.com, sos@freefall.freebsd.org, freeBSD-arch@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG Subject: Re: cvs commit: src/sys/scsi sd.c In-reply-to: Your message of "Fri, 02 May 1997 08:28:01 +1000." <199705012228.IAA29072@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 May 1997 18:11:20 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>1) What should sd and other devices drivers "see" by the time they receive >>the I/O? Should b_blkno always be in terms of the logical block size of >>the device or should the device driver be responsible for scaling? > >Note that b_blkno is normally not used after dscheck(). dscheck() does >conversions as well as checks, leaving the final block number in b_pblkno. >It's probably best for b_blkno to always be in DEV_BSIZE units and >b_pblkno to be in terms of the physical block size. This seems to be >the case in sd.c now. b_blkno is scaled to physical units so dscheck() >returns b_pblkno in physical units. b_blkno is scaled back to logical >units and b_pblkno is sent to the controller. I think b_blkno is only >used again if there is an error (diskerr() uses it). So dscheck should do the conversion based on the sector size in the disklabel? >>3) What features do we want to support? Do we want to support the ability >>to 'dd' an image from a 512byte sectored device to a 1k sectored device >>and have it work? If so, what constraints are needed? (disklabel has >>the larger block size even on the smaller sector sized disk? or is it just >>that your frag and fs block sizes need to be in sync?) > >I think that this is too hard to be worth supporting. It can't work in >general, because the source partitions might have a size that is not a >multiple of the target block size. Does any of this discussion affect the vn driver? What about being able to create an ISOFS on a hard drive? Do we only support that via vn? >>4) If we want to have partitions with the only constraint being that they >>begin and end on a sector boundary, what else in the system needs to change >>to allow this? How does this affect 2 and 3? > >You also need to constrain file system fragment sizes to a multiple of >the sector size for a simple implementation. I think only sizes of 512, >1024, 2048 and 4096 are practical. So newfs needs to consult the disklabel and ensure that the frag/block size is a a power of 2 multiple of the physical sector size in the disklabel. >Bruce -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Thu May 1 16:44:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA26034 for freebsd-scsi-outgoing; Thu, 1 May 1997 16:44:10 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA25924; Thu, 1 May 1997 16:43:12 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id JAA32257; Fri, 2 May 1997 09:38:28 +1000 Date: Fri, 2 May 1997 09:38:28 +1000 From: Bruce Evans Message-Id: <199705012338.JAA32257@godzilla.zeta.org.au> To: bde@zeta.org.au, gibbs@plutotech.com Subject: Re: cvs commit: src/sys/scsi sd.c Cc: freeBSD-arch@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG, sos@freefall.freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >So dscheck should do the conversion based on the sector size in the >disklabel? Yes. I'm not sure if we can trust the on-disk value, but drivers set it before calling dsopen() and dsopen() is a good place to convert it to a more convenient form (take log2(d_secsize) and use this for shifts). >Does any of this discussion affect the vn driver? What about being >able to create an ISOFS on a hard drive? Do we only support that via >vn? vn could always use 512-byte "sectors', but it needs to know about the device block size to avoid using the VOP_STRATEGY() interface for non-physical-block requests. It would be useful for debugging for vn to support arbitrary "sector" sizes. I'm not sure if cd9660 on vn works now. I think it does because cd9660 talks to drivers in 512-blocks. >>You also need to constrain file system fragment sizes to a multiple of >>the sector size for a simple implementation. I think only sizes of 512, >>1024, 2048 and 4096 are practical. > >So newfs needs to consult the disklabel and ensure that the frag/block size >is a a power of 2 multiple of the physical sector size in the disklabel. If we limit it to powers of 2. It would be nice to have support for weird sizes as a stream of blocks. I just don't see putting file systems on them. Bruce From owner-freebsd-scsi Thu May 1 19:31:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA05771 for freebsd-scsi-outgoing; Thu, 1 May 1997 19:31:25 -0700 (PDT) Received: from math.berkeley.edu (math.Berkeley.EDU [128.32.183.94]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA05764; Thu, 1 May 1997 19:31:23 -0700 (PDT) Received: by math.berkeley.edu (8.7.5/1.33(math)Ow.3) id TAA24685; Thu, 1 May 1997 19:31:20 -0700 (PDT) Date: Thu, 1 May 1997 19:31:20 -0700 (PDT) From: dan@math.berkeley.edu (Dan Strick) Message-Id: <199705020231.TAA24685@math.berkeley.edu> To: freeBSD-arch@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG Subject: Re: cvs commit: src/sys/scsi sd.c Cc: dan@math.berkeley.edu Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > 1) What should sd and other devices drivers "see" by the time they receive > the I/O? Should b_blkno always be in terms of the logical block size of > the device or should the device driver be responsible for scaling? > ... There are really two different problems here. One is how we communicate the device address to the device driver and the other is what we do if the requested I/O operation does not begin and end at block boundaries. The main limitations of the current convention, passing a bock number in b_blkno, is that it forces applications using the device to know what the block size is and it does not allow specification of an arbitrary byte address. The most straight forward fix is to change the block number to a byte number, but this would force significant change in other parts of the OS and there may be some value in having the OS know something about device block sizes. Therefore I recommend adding a b_bytoff field to the buffer structure and a device block size field to some appropriate per device structure. The block size would default to 512 bytes so that existing code wouldn't need to be changed. Byte addressed devices could use a block size of 1 and ignore the byte offset. Since the OS would know the block size, it could be extended to provide more general data blocking services (e.g. a generalized physio routine that knows how to read or modify just a part of a physical device block). Programs could exchange block size information with each other and the kernel in a general way and the device address could be made to mean something for tapes operating in a variable record size mode. In practice, nearly all disk applications will like block sizes that are a power of two, so special code might be written to optimize for that specific situation but the general case should be implemented anyway. It only takes a little extra code and that code won't be used unless it is needed. (Hint: a buffer size is a power of two iff (size-1)^size == 0.) Several years ago I did something like this for a SunOS SCSI disk driver and was quite pleased with the results. The OS would seldom do I/O not aligned on a file system block boundary (8kb) and consequently there was essentially no performance problem (and CR-ROMS with a 2K block size worked!). Dan Strick dan@math.berkeley.edu From owner-freebsd-scsi Thu May 1 23:50:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA17132 for freebsd-scsi-outgoing; Thu, 1 May 1997 23:50:02 -0700 (PDT) Received: from ravenock.cybercity.dk (ravenock.cybercity.dk [195.8.129.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA17101; Thu, 1 May 1997 23:49:44 -0700 (PDT) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.5/8.7.3) id IAA16854; Fri, 2 May 1997 08:49:57 +0200 (MEST) From: Søren Schmidt Message-Id: <199705020649.IAA16854@ravenock.cybercity.dk> Subject: Re: cvs commit: src/sys/scsi sd.c In-Reply-To: <199705012228.IAA29072@godzilla.zeta.org.au> from Bruce Evans at "May 2, 97 08:28:01 am" To: bde@zeta.org.au (Bruce Evans) Date: Fri, 2 May 1997 08:49:56 +0200 (MEST) Cc: bde@zeta.org.au, gibbs@plutotech.com, sos@freefall.freebsd.org, freeBSD-arch@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Bruce Evans who wrote: > >We need to really think about how we want to handle media with block > >sizes greater than DEV_BSIZE. Some questions to answer are: > > disklabel.h says that the sizes in the label are in "sectors", and > I think it is best to use physical sectors in labels and in-core > slice tables. > > >1) What should sd and other devices drivers "see" by the time they receive > >the I/O? Should b_blkno always be in terms of the logical block size of > >the device or should the device driver be responsible for scaling? > > Note that b_blkno is normally not used after dscheck(). dscheck() does > conversions as well as checks, leaving the final block number in b_pblkno. > It's probably best for b_blkno to always be in DEV_BSIZE units and > b_pblkno to be in terms of the physical block size. This seems to be > the case in sd.c now. b_blkno is scaled to physical units so dscheck() > returns b_pblkno in physical units. b_blkno is scaled back to logical > units and b_pblkno is sent to the controller. I think b_blkno is only > used again if there is an error (diskerr() uses it). This is essentially what is being done now, just its code inserted in sd.c instead of generically in dscheck(). I think the authors did this to do it with as little impact as possible. The same thing is done in od.c (it was there allready, they just made it work). This ougth to be pretty easy to do. I'll take a plounge at it as I guess I'm the only one with those odd disks :) > >2) If we decide that it really should be in terms of the logical block size > >of the device, what consequences does this have on information in the > >disklabel and how it's used by other areas of the kernel? > > No consequences, I hope. The kernel can continue to use 512-byte blocks > except in labeling code and drivers. There allready is code in place to handle this, also iin fdisk & newfs. > >3) What features do we want to support? Do we want to support the ability > >to 'dd' an image from a 512byte sectored device to a 1k sectored device > >and have it work? If so, what constraints are needed? (disklabel has > >the larger block size even on the smaller sector sized disk? or is it just > >that your frag and fs block sizes need to be in sync?) > > I think that this is too hard to be worth supporting. It can't work in > general, because the source partitions might have a size that is not a > multiple of the target block size. No, lets not get into that... > >4) If we want to have partitions with the only constraint being that they > >begin and end on a sector boundary, what else in the system needs to change > >to allow this? How does this affect 2 and 3? > > You also need to constrain file system fragment sizes to a multiple of > the sector size for a simple implementation. I think only sizes of 512, > 1024, 2048 and 4096 are practical. Yes, this is also nessesary for the current model. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-scsi Fri May 2 10:46:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA12601 for freebsd-scsi-outgoing; Fri, 2 May 1997 10:46:45 -0700 (PDT) Received: from sendero.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA12590 for ; Fri, 2 May 1997 10:46:26 -0700 (PDT) Received: (qmail 6822 invoked by uid 1000); 2 May 1997 17:20:56 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD X-PRIORITY: 2 (High) Priority: urgent Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Fri, 02 May 1997 10:08:18 -0700 (PDT) Organization: iConnect Corp. From: Simon Shapiro To: freebsd-scsi@freebsd.org Subject: Multiple Busses, HowTo Question Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Yall, I am getting to the point where I really need an answer to the question. Here is the situation: The DPT SCSi HBA has up to three busses per HBA. It is a bit unlike the Adaptec or the Mylex solution in that there is really only one HBA (one set of registers, etc.), but the HBA has 1,2, or 3 busses. We know how to detect it at initialization time and how to address them. What we do not know, is how to tell FreeBSD about it. Here is what we did: 1. We have one softc structure for each HBA. 2. In the softc, we maintain a count of how many busses we found. 3. In the softc, we have an array of scsi_link structures. One per bus. 4. In the config file we have 3 scsi busses: controller dpt0 controller scbus0 at dpt0 controller scbus1 at dpt0 controller scbus2 at dpt0 disk sd0 at scbus0 target 0 unit 0 disk sd1 at scbus0 target 1 unit 0 disk sd2 at scbus0 target 2 unit 0 disk sd3 at scbus0 target 3 unit 0 disk sd4 at scbus0 target 4 unit 0 ... disk sd16 at scbus1 target 0 unit 0 disk sd17 at scbus1 target 1 unit 0 disk sd18 at scbus1 target 2 unit 0 disk sd19 at scbus1 target 3 unit 0 disk sd20 at scbus1 target 4 unit 0 ... disk sd128 at scbus0 target 0 unit 1 disk sd129 at scbus0 target 1 unit 1 disk sd130 at scbus0 target 2 unit 1 disk sd131 at scbus0 target 3 unit 1 disk sd132 at scbus0 target 4 unit 1 ... What we see is that scsi_attachdevs() calls dpt0 with ALL the three busses, without any visible (to us) indication which bus should the request go to. The QUESTION: Should we create a separate softc for each bus, or is there a way to differentiate the busses? Thanx a million! Simon solution in that there is really only one HBA (one set of registers, etc.), but the HBA has 1,2, or 3 busses. We know how to detect it at initialization time and how to address them. What we do not know, is how to tell FreeB From owner-freebsd-scsi Fri May 2 12:45:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA18995 for freebsd-scsi-outgoing; Fri, 2 May 1997 12:45:53 -0700 (PDT) Received: from pluto.plutotech.com (root@pluto100.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA18990 for ; Fri, 2 May 1997 12:45:51 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.3) with ESMTP id NAA16949; Fri, 2 May 1997 13:45:35 -0600 (MDT) Message-Id: <199705021945.NAA16949@pluto.plutotech.com> To: Simon Shapiro cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Multiple Busses, HowTo Question In-reply-to: Your message of "Fri, 02 May 1997 10:08:18 PDT." Date: Fri, 02 May 1997 14:44:12 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Hi Yall, > >I am getting to the point where I really need an answer to the question. > >Here is the situation: > >The DPT SCSi HBA has up to three busses per HBA. It is a bit unlike the >Adaptec or the Mylex solution in that there is really only one HBA (one set >of registers, etc.), but the HBA has 1,2, or 3 busses. We know how to >detect it at initialization time and how to address them. What we do not >know, is how to tell FreeBSD about it. Go look at the Adaptec driver. Your situation is much the same as that of the 274XT controllers (2 busses but only one HBA) and you should be able to use the aic7xxx.c file as an example of how to properly perform the attach. >controller dpt0 > >controller scbus0 at dpt0 >controller scbus1 at dpt0 >controller scbus2 at dpt0 These should be: controller scbus0 at dpt0 bus 0 controller scbus1 at dpt0 bus 1 controller scbus2 at dpt0 bus 2 "man 4 scsi" and you'll see an example for the 2742. >What we see is that scsi_attachdevs() calls dpt0 with ALL the three busses, >without any visible (to us) indication which bus should the request go to. You are supposed to key off of the "adapter_bus" member of the scsi_link structure pointed to by the scsi_xfer passed into you: xs->sc_link->adapter_bus This also means that you must properly initialize the adapter_bus member of the scsi_link structure you pass into scsi_attachdevs(). BTW Simon, you're putting out garbage at the end of your messages again... -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Fri May 2 13:20:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA20635 for freebsd-scsi-outgoing; Fri, 2 May 1997 13:20:51 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA20628 for ; Fri, 2 May 1997 13:20:48 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA25488 for freeBSD-scsi@FreeBSD.ORG; Fri, 2 May 1997 22:20:40 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id WAA00534; Fri, 2 May 1997 22:10:44 +0200 (MET DST) Message-ID: <19970502221044.EH53977@uriah.heep.sax.de> Date: Fri, 2 May 1997 22:10:44 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freeBSD-scsi@FreeBSD.ORG Subject: Re: cvs commit: src/sys/scsi sd.c References: <199705012023.GAA24197@godzilla.zeta.org.au> <199705012119.PAA20788@pluto.plutotech.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199705012119.PAA20788@pluto.plutotech.com>; from Justin T. Gibbs on May 1, 1997 16:17:24 -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Justin T. Gibbs wrote: > 3) What features do we want to support? Do we want to support the ability > to 'dd' an image from a 512byte sectored device to a 1k sectored device > and have it work? No. Raw device access is restricted to the physical block size. This is already enforced in the floppy driver, which is capable of handling 1 KB physical sectors. This is, for example, enforced in the worm(4) driver when writing audio frames: the blocksize must be a multiple of 2352 bytes. This will be enforced in a CD-DA reading mode of the cd(4) driver, if i ever get around to implement it. :) > 4) If we want to have partitions with the only constraint being that they > begin and end on a sector boundary, what else in the system needs to change > to allow this? How does this affect 2 and 3? IIRC, the biggest problem was the UFS filesystem code assuming everything can be aligned to DEV_BSIZE. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)