From admin at yar.bcs.ru Wed Sep 3 09:58:45 2008 From: admin at yar.bcs.ru (=?koi8-r?B?7s/Xz9DB28nOIPfB08nMyco=?=) Date: Wed Sep 3 11:33:52 2008 Subject: rl driver for freebsd Message-ID: <8014519171.20080903133025@yar.bcs.ru> ?????? freebsd-drivers, Hello! I use driver rl from Realtek Semiconductor corp on Realtek RTL8111C and RTL8102EL driver rtl_bsd_drv_v176.tgz I have tested this driver RTL8111C on freebsd 5.4. it is working well 24x7 more 70 days. And I have tested this driver RTL8102EL on freebsd 6.2. it is working well. And may frend have tested this driver RTL8111C on freebsd 6.3. He say: it is working well. I`d like to see this driver in new version FreeBSD. download from www.realtek.com.tw quick links ftp://66.104.77.130/cn/nic/rtl_bsd_drv_v176.tgz ftp://202.65.194.212/cn/nic/rtl_bsd_drv_v176.tgz ftp://61.56.86.122/cn/nic/rtl_bsd_drv_v176.tgz -- ? ?????????, ??????? ?????????, ????????? ????????????? ??????????? ?????????????? ???? ??? "???????? ??????????????????" (4852) 406-426, 406-425 From thomas.elsgaard at gmail.com Wed Sep 3 20:29:14 2008 From: thomas.elsgaard at gmail.com (Thomas Elsgaard) Date: Wed Sep 3 20:29:20 2008 Subject: Support for sierra wireless MC8790 Message-ID: <48BEEEA6.9070601@gmail.com> Hello guys Does anybody know if there in FreeBSD is a driver for the sierra wireless MC8790?, and in which version? Or has anybody tried to get it working in some way? Regards ///Thomas From raul at b2n.org Sat Sep 6 18:21:14 2008 From: raul at b2n.org (Raul) Date: Sat Sep 6 18:21:21 2008 Subject: Adaptec AAR-1225SA REV A2, Help! Message-ID: <1220724123.6519.8.camel@ws.pinlabs.b2n.org> Hello driver gurus! I have read somewhere that the adaptec AAR-1225SA is based on SiI3132 and the ata man page says that this chip is supported so I have bought one of them today. The chip in fact says: Silicon Image TM SII3132CNU QM2517.1-1 AD02CX2 but sadly, my RELENG_7 (amd64, compiled yesterday) pciconf reports: none0@pci0:7:0:0: class=0x010401 card=0x02449005 chip=0x02441095 rev=0x01 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' class = mass storage subclass = RAID May I do something to get this controller working? Thanks a lot in advance, Raul. From volker at vwsoft.com Sat Sep 6 20:49:02 2008 From: volker at vwsoft.com (Volker) Date: Sat Sep 6 20:49:08 2008 Subject: Adaptec AAR-1225SA REV A2, Help! In-Reply-To: <1220724123.6519.8.camel@ws.pinlabs.b2n.org> References: <1220724123.6519.8.camel@ws.pinlabs.b2n.org> Message-ID: <48C2E55F.9000901@vwsoft.com> On 09/06/08 20:02, Raul wrote: > Hello driver gurus! > > I have read somewhere that the adaptec AAR-1225SA is based on SiI3132 > and the ata man page says that this chip is supported so I have bought > one of them today. > > The chip in fact says: > > Silicon Image TM > SII3132CNU > QM2517.1-1 > AD02CX2 > > but sadly, my RELENG_7 (amd64, compiled yesterday) pciconf reports: > > none0@pci0:7:0:0: class=0x010401 card=0x02449005 chip=0x02441095 > rev=0x01 hdr=0x00 > vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' > class = mass storage > subclass = RAID > > May I do something to get this controller working? > > Thanks a lot in advance, > Raul. > Raul, the ata driver does not know anything about the device ID. Try the attached patches and rebuild kernel. Volker -------------- next part -------------- A non-text attachment was scrubbed... Name: ata-chipset.diff Type: text/x-patch Size: 682 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-drivers/attachments/20080906/d674ee6f/ata-chipset.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ata-pci.diff Type: text/x-patch Size: 435 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-drivers/attachments/20080906/d674ee6f/ata-pci.bin From raul at b2n.org Sun Sep 7 09:36:20 2008 From: raul at b2n.org (Raul) Date: Sun Sep 7 09:36:38 2008 Subject: [Fwd: Re: Adaptec AAR-1225SA REV A2, Help!] Message-ID: <1220780177.6468.3.camel@ws.pinlabs.b2n.org> Ops!, maybe the list is also interested ;) Raul --------- Mensaje reenviado -------- De: Raul Para: Volker Asunto: Re: Adaptec AAR-1225SA REV A2, Help! Fecha: Sun, 07 Sep 2008 00:46:43 +0200 El s?b, 06-09-2008 a las 22:17 +0200, Volker escribi?: > the ata driver does not know anything about the device ID. > > Try the attached patches and rebuild kernel. It looks prety good. Thanks a lot! >From pciconf -l -v [....] atapci0@pci0:7:0:0: class=0x010401 card=0x02449005 chip=0x02441095 rev=0x01 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' class = mass storage subclass = RAID [....] from dmesg: [....] atapci0: port 0xdc80-0xdcff mem 0xfe5ffc00-0xfe5ffc7f,0xfe5f8000-0xfe5fbfff irq 16 at device 0.0 on pci7 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] [....] I have a couple of disks attached to it that, at first sight, also look fine. Is there any battery test to be sure that was only a device ID shift?. Raul From raul at b2n.org Mon Sep 8 16:26:35 2008 From: raul at b2n.org (Raul) Date: Mon Sep 8 16:26:42 2008 Subject: Adaptec AAR-1225SA REV A2, solved! In-Reply-To: <48C2E55F.9000901@vwsoft.com> References: <1220724123.6519.8.camel@ws.pinlabs.b2n.org> <48C2E55F.9000901@vwsoft.com> Message-ID: <1220891191.6842.20.camel@ws.pinlabs.b2n.org> El s?b, 06-09-2008 a las 22:17 +0200, Volker escribi?: [....] > the ata driver does not know anything about the device ID. > > Try the attached patches and rebuild kernel. After some more use, still looks pretty good. I have seen that on rev. 1.90 of ata-pci.h, the 1220SA is already supported. Any chance to get your patch for the 1225SA on the tree?. It would be great have it supported on RELENG_7 some day OXD. Thanks a lot Volker!. Raul From jhb at freebsd.org Mon Sep 8 20:12:37 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Sep 8 20:12:44 2008 Subject: [Review request]: Attansic L2 ethernet driver In-Reply-To: <20080831222822.76d4ee92.stas@FreeBSD.org> References: <20080831222822.76d4ee92.stas@FreeBSD.org> Message-ID: <200809081456.56064.jhb@freebsd.org> On Sunday 31 August 2008 02:28:22 pm Stanislav Sedov wrote: > Hi! > > Seems that I've implemented the most stuff I wanted > to see in the driver for Attansic L2 ethernet controller. > I haven't received any bugreports since the last public > version and I think it's in a pretty good form and ready > to be committed in HEAD. Before that, I'd like to ask > you to review the code of the driver, since it's my > first work in this area, and I'm not sure I've done > everything correctly. > > The latest diff against HEAD is available here: > http://www.SpringDaemons.com/stas/if_ae.diff.2008083100 A few style notes: - return (FILTER_STRAY) (missing ()'s) - Extra indentation for one of the TASK_INIT()'s - Are you using 4 space indent or 8 space indent? -- John Baldwin From volker at vwsoft.com Mon Sep 8 21:35:09 2008 From: volker at vwsoft.com (Volker) Date: Mon Sep 8 21:35:16 2008 Subject: Adaptec AAR-1225SA REV A2, solved! In-Reply-To: <1220891191.6842.20.camel@ws.pinlabs.b2n.org> References: <1220724123.6519.8.camel@ws.pinlabs.b2n.org> <48C2E55F.9000901@vwsoft.com> <1220891191.6842.20.camel@ws.pinlabs.b2n.org> Message-ID: <48C59A7A.9090102@vwsoft.com> On 09/08/08 18:26, Raul wrote: > El s??b, 06-09-2008 a las 22:17 +0200, Volker escribi??: > > [....] >> the ata driver does not know anything about the device ID. >> >> Try the attached patches and rebuild kernel. > > After some more use, still looks pretty good. > > I have seen that on rev. 1.90 of ata-pci.h, the 1220SA is already > supported. Any chance to get your patch for the 1225SA on the tree?. It > would be great have it supported on RELENG_7 some day OXD. > > Thanks a lot Volker!. > > Raul > Raul, sorry for delay - too much work. First you may try how your IDE adapter behaves under load. Older SiI chips used to work fine for light load but refused to work under load (in terms of write operations). I don't know if this is still true for these newer chips. For the commit: 1) I don't have a commit bit, but we may get that in (by the help of somebody else) 2) we're already in a freeze situation - don't expect that to be in -STABLE before 7.1-RELEASE (also it needs to be in HEAD first and then may get MFC'd). Thanks for reporting! Volker PS: Can you please file a PR with my patch attached? I'm missing some time to do that (this way, the change doesn't get lost). From raul at b2n.org Thu Sep 11 06:06:17 2008 From: raul at b2n.org (Raul) Date: Thu Sep 11 06:06:24 2008 Subject: Adaptec AAR-1225SA REV A2, solved! In-Reply-To: <48C59A7A.9090102@vwsoft.com> References: <1220724123.6519.8.camel@ws.pinlabs.b2n.org> <48C2E55F.9000901@vwsoft.com> <1220891191.6842.20.camel@ws.pinlabs.b2n.org> <48C59A7A.9090102@vwsoft.com> Message-ID: <1221113173.6481.36.camel@ws.pinlabs.b2n.org> El lun, 08-09-2008 a las 23:34 +0200, Volker escribi?: > First you may try how your IDE adapter behaves under load. Older SiI > chips used to work fine for light load but refused to work under load > (in terms of write operations). I don't know if this is still true for > these newer chips. Well, I'm not sure how much load do you mean so I'll tell you what I did ;). I've set a striped zvol and push 4 parallel dd reading from /dev/zero and 8 tars decompresing src's and ports tarballs. Just to add some 'noise' to the box, a buildworld was also running although from other disk behind other controller ... after some time, the noise coming from the disks changed, I thought, something has happened ... well, tar finished successfully and only the 4 dd continue writing on the zvol. About 6?GB on disk and several thousand files ... So I stop the dd's and run a scrub on the zvol that was completed with 0 errors. After that, I destroyed the striped zvol and set a mirrored one. From them, samba shares, some netcat, scp's ... 24GB has been writen with a more 'normal' load and still without any apparent problem. I don't like too much this _scientific_ approach, but I feel pretty confident about the controller ;). > For the commit: > > 1) I don't have a commit bit, but we may get that in (by the help of > somebody else) > 2) we're already in a freeze situation - don't expect that to be in > -STABLE before 7.1-RELEASE (also it needs to be in HEAD first and then > may get MFC'd). I see. [....] > PS: Can you please file a PR with my patch attached? I'm missing some > time to do that (this way, the change doesn't get lost). Yes, I'll do that. Thanks a lot Volker. Raul From stas at FreeBSD.org Thu Sep 18 21:06:55 2008 From: stas at FreeBSD.org (Stanislav Sedov) Date: Thu Sep 18 21:07:07 2008 Subject: [Review request]: Attansic L2 ethernet driver In-Reply-To: <200809081456.56064.jhb@freebsd.org> References: <20080831222822.76d4ee92.stas@FreeBSD.org> <200809081456.56064.jhb@freebsd.org> Message-ID: <20080919010648.2b1ca962.stas@FreeBSD.org> On Mon, 8 Sep 2008 14:56:55 -0400 John Baldwin mentioned: > A few style notes: > - return (FILTER_STRAY) (missing ()'s) > - Extra indentation for one of the TASK_INIT()'s > - Are you using 4 space indent or 8 space indent? > Thanks! Pyun YongHyeon also gave a lot of comments on code, so I'm working on fixing these. My indentation is standard one: one tab for 1st level indents, and four spaces for second. -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-drivers/attachments/20080918/f5f526ba/attachment.pgp From sbruno at miralink.com Mon Sep 22 17:51:02 2008 From: sbruno at miralink.com (Sean Bruno) Date: Mon Sep 22 17:51:04 2008 Subject: [RELENG_6] ATARAID oddity Message-ID: <48D7DB05.6050907@miralink.com> I stumbled upon some strange behavior when conducting some SCSI target testing in my lab that caused me to do a double-take. If a FreeBSD system detects a drive with Adaptec RAID controller meta data on it, the ataraid() driver will attempt to interpret that data as a real volume. It makes no difference to the ataraid() driver if there is an Adaptec controller physically present in the system or not. I.e. if you insert a drive that was part of a volume from an Adaptec RAID controller into another system, the new system will attempt to treat that disk as though it were associated with a HOST Raid controller. I don't think that this is the desired behavior. Even if the host raid meta-data is detected, the system shouldn't attempt to treat the disk as part of a HOST raid set without the appropriate controller in the system. -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com From freebsd at sopwith.solgatos.com Mon Sep 22 22:38:58 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Mon Sep 22 22:39:00 2008 Subject: [RELENG_6] ATARAID oddity In-Reply-To: Your message of "Mon, 22 Sep 2008 10:51:01 PDT." <48D7DB05.6050907@miralink.com> Message-ID: <200809222203.WAA20882@sopwith.solgatos.com> > I.e. if you insert a drive that was part of a volume from an Adaptec > RAID controller into another system, the new system will attempt to > treat that disk as though it were associated with a HOST Raid controller. > > I don't think that this is the desired behavior. Even if the host raid > meta-data is detected, the system shouldn't attempt to treat the disk as > part of a HOST raid set without the appropriate controller in the system. Even if there *is* an appropriate controller in the system, presumably it isn't going to work unless the disk is connected to that controller. We want the ability to migrate a disk from Adaptec to some other controller without screwy things happening. From sbruno at miralink.com Mon Sep 22 23:24:26 2008 From: sbruno at miralink.com (Sean Bruno) Date: Mon Sep 22 23:24:29 2008 Subject: [RELENG_6] ATARAID oddity In-Reply-To: <200809222203.WAA20882@sopwith.solgatos.com> References: <200809222203.WAA20882@sopwith.solgatos.com> Message-ID: <48D82921.3010904@miralink.com> Dieter wrote: >> I.e. if you insert a drive that was part of a volume from an Adaptec >> RAID controller into another system, the new system will attempt to >> treat that disk as though it were associated with a HOST Raid controller. >> >> I don't think that this is the desired behavior. Even if the host raid >> meta-data is detected, the system shouldn't attempt to treat the disk as >> part of a HOST raid set without the appropriate controller in the system. >> > > Even if there *is* an appropriate controller in the system, presumably it > isn't going to work unless the disk is connected to that controller. > > We want the ability to migrate a disk from Adaptec to some other > controller without screwy things happening. > _______________________________________________ Looking over the ata-raid.c code that controls the detection, it's pretty obvious that it doesn't check to see if the disk belongs to a controller. Moreover it blindly tries to use ANY drive in the system(LSI will do this as well) if it detects meta data. I'm working on a simple patch for this, but I need to figure out which cards are using the Adaptec metadata format. Any ideas where I should look? I seem to have 1 card available(3010S) that I can validate against. -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com From sbruno at miralink.com Tue Sep 23 02:40:45 2008 From: sbruno at miralink.com (Sean Bruno) Date: Tue Sep 23 02:40:47 2008 Subject: [RELENG_6] ATARAID oddity In-Reply-To: <48D82921.3010904@miralink.com> References: <200809222203.WAA20882@sopwith.solgatos.com> <48D82921.3010904@miralink.com> Message-ID: <48D8572B.3060204@miralink.com> Sean Bruno wrote: > Dieter wrote: >>> I.e. if you insert a drive that was part of a volume from an Adaptec >>> RAID controller into another system, the new system will attempt to >>> treat that disk as though it were associated with a HOST Raid >>> controller. >>> >>> I don't think that this is the desired behavior. Even if the host >>> raid meta-data is detected, the system shouldn't attempt to treat >>> the disk as part of a HOST raid set without the appropriate >>> controller in the system. >>> >> >> Even if there *is* an appropriate controller in the system, >> presumably it >> isn't going to work unless the disk is connected to that controller. >> >> We want the ability to migrate a disk from Adaptec to some other >> controller without screwy things happening. >> _______________________________________________ > Looking over the ata-raid.c code that controls the detection, it's > pretty obvious > that it doesn't check to see if the disk belongs to a controller. > Moreover it > blindly tries to use ANY drive in the system(LSI will do this as well) > if it detects > meta data. > > I'm working on a simple patch for this, but I need to figure out > which cards are > using the Adaptec metadata format. Any ideas where I should look? I > seem to have > 1 card available(3010S) that I can validate against. > > Well, I tried out this little patch for my system. This probably breaks a lot of stuff, but it's the beginning of what I think is more correct behavior for Adaptec Host-RAID. If anyone has Adaptec Host-RAID systems out there, please send me the PCI-IDs of your boards before your try this patch. I would assume that there are some Host RAID adapters out there that don't conform to the pci-ids I have put in this patch. If you have one, let me know. -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Cell 503-358-6832 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: ata_adaptec.diff Type: text/x-patch Size: 1809 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-drivers/attachments/20080923/454c6cef/ata_adaptec.bin From hsakamt at tsnr.com Tue Sep 23 04:27:22 2008 From: hsakamt at tsnr.com (Hideki Sakamoto) Date: Tue Sep 23 04:27:24 2008 Subject: [RELENG_6] ATARAID oddity In-Reply-To: <200809222203.WAA20882@sopwith.solgatos.com> References: <200809222203.WAA20882@sopwith.solgatos.com> Message-ID: <48D86B85.8050304@tsnr.com> Hi, > Even if there *is* an appropriate controller in the system, presumably it > isn't going to work unless the disk is connected to that controller. As far as understanding, ataraid is software RAID and meta data is just used to determine whether a HDD is member of a RAID-set or not. And I think it's probably work even if there is no consistency between a meta data format and Controler Chip under the situation that the Controller is attached with and controlled by ATA(ad?) driver. This behavior may be useful in trouble shooting(e.g. Controller is dead, all HDD is OK, but I only have the motherboard with different ATA Controller Chip I used). So I think it's interesting to consider an (optional) implementation of: The ataraid driver can recognize any supported meta data format with all supportd Controller Chip. If you want to use a HDD which is used as member of ataraid in past time. You must delete or overwrite meta data on HDD by hand using atacontrol(8). Thanks, Dieter said: >> I.e. if you insert a drive that was part of a volume from an Adaptec >> RAID controller into another system, the new system will attempt to >> treat that disk as though it were associated with a HOST Raid controller. >> >> I don't think that this is the desired behavior. Even if the host raid >> meta-data is detected, the system shouldn't attempt to treat the disk as >> part of a HOST raid set without the appropriate controller in the system. > > Even if there *is* an appropriate controller in the system, presumably it > isn't going to work unless the disk is connected to that controller. > > We want the ability to migrate a disk from Adaptec to some other > controller without screwy things happening. > _______________________________________________ > freebsd-drivers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-drivers > To unsubscribe, send any mail to "freebsd-drivers-unsubscribe@freebsd.org" From sos at FreeBSD.ORG Tue Sep 23 07:20:14 2008 From: sos at FreeBSD.ORG (=?ISO-8859-1?Q?S=F8ren_Schmidt?=) Date: Tue Sep 23 07:20:17 2008 Subject: [RELENG_6] ATARAID oddity In-Reply-To: <48D8572B.3060204@miralink.com> References: <200809222203.WAA20882@sopwith.solgatos.com> <48D82921.3010904@miralink.com> <48D8572B.3060204@miralink.com> Message-ID: Hi Just the short version: Since this is softraids and the different vendors use different chips, there is no 1 to 1 relation between raid type and controller PCI id. Its a puzzle you cannot solve without loosing a good percentage of the systems out there. -S?ren On 23Sep, 2008, at 4:40 , Sean Bruno wrote: > Sean Bruno wrote: >> Dieter wrote: >>>> I.e. if you insert a drive that was part of a volume from an >>>> Adaptec RAID controller into another system, the new system will >>>> attempt to treat that disk as though it were associated with a >>>> HOST Raid controller. >>>> >>>> I don't think that this is the desired behavior. Even if the >>>> host raid meta-data is detected, the system shouldn't attempt to >>>> treat the disk as part of a HOST raid set without the appropriate >>>> controller in the system. >>>> >>> >>> Even if there *is* an appropriate controller in the system, >>> presumably it >>> isn't going to work unless the disk is connected to that controller. >>> >>> We want the ability to migrate a disk from Adaptec to some other >>> controller without screwy things happening. >>> _______________________________________________ >> Looking over the ata-raid.c code that controls the detection, it's >> pretty obvious >> that it doesn't check to see if the disk belongs to a controller. >> Moreover it >> blindly tries to use ANY drive in the system(LSI will do this as >> well) if it detects >> meta data. >> >> I'm working on a simple patch for this, but I need to figure out >> which cards are >> using the Adaptec metadata format. Any ideas where I should look? >> I seem to have >> 1 card available(3010S) that I can validate against. >> >> > Well, I tried out this little patch for my system. This probably > breaks a lot of stuff, but > it's the beginning of what I think is more correct behavior for > Adaptec Host-RAID. > > If anyone has Adaptec Host-RAID systems out there, please send me > the PCI-IDs of your > boards before your try this patch. I would assume that there are > some Host RAID adapters > out there that don't conform to the pci-ids I have put in this > patch. If you have one, let me know. > > -- > Sean Bruno > MiraLink Corporation > 6015 NE 80th Ave, Ste 100 > Portland, OR 97218 > Cell 503-358-6832 > Phone 503-621-5143 > Fax 503-621-5199 > MSN: sbruno@miralink.com > Google: seanwbruno@gmail.com > > Index: ata-pci.c > =================================================================== > --- ata-pci.c (revision 5956) > +++ ata-pci.c (working copy) > @@ -532,6 +532,7 @@ > switch (pci_get_vendor(dev)) { > case ATA_ACARD_ID: return "Acard"; > case ATA_ACER_LABS_ID: return "AcerLabs"; > + case ATA_ADAPTEC_ID: return "Adaptec"; > case ATA_AMD_ID: return "AMD"; > case ATA_ATI_ID: return "ATI"; > case ATA_CYRIX_ID: return "Cyrix"; > Index: ata-raid.c > =================================================================== > --- ata-raid.c (revision 5956) > +++ ata-raid.c (working copy) > @@ -1304,6 +1304,12 @@ > /* prioritize vendor native metadata layout if possible */ > if (devclass == pci_devclass) { > switch (pci_get_vendor(GRANDPARENT(device_get_parent(subdisk)))) { > + /* Adaptec HostRAID */ > + case ATA_ADAPTEC_ID: > + if (ata_raid_adaptec_read_meta(subdisk, ata_raid_arrays)) > + return 0; > + break; > + > case ATA_HIGHPOINT_ID: > if (ata_raid_hptv3_read_meta(subdisk, ata_raid_arrays)) > return 0; > @@ -1358,10 +1364,6 @@ > /* handle controllers that have multiple layout possibilities */ > /* NOTE: the order of these are not insignificant */ > > - /* Adaptec HostRAID */ > - if (ata_raid_adaptec_read_meta(subdisk, ata_raid_arrays)) > - return 0; > - > /* LSILogic v3 and v2 */ > if (ata_raid_lsiv3_read_meta(subdisk, ata_raid_arrays)) > return 0; > Index: ata-pci.h > =================================================================== > --- ata-pci.h (revision 5956) > +++ ata-pci.h (working copy) > @@ -71,6 +71,8 @@ > }; > > /* defines for known chipset PCI id's */ > +#define ATA_ADAPTEC_ID 0x1044 > + > #define ATA_ACARD_ID 0x1191 > #define ATA_ATP850 0x00021191 > #define ATA_ATP850A 0x00041191 -S?ren From freebsd at sopwith.solgatos.com Tue Sep 23 16:14:38 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Tue Sep 23 16:14:44 2008 Subject: [RELENG_6] ATARAID oddity In-Reply-To: Your message of "Mon, 22 Sep 2008 10:51:01 PDT." <48D7DB05.6050907@miralink.com> Message-ID: <200809231611.QAA05934@sopwith.solgatos.com> Sean Bruno writes: > If a FreeBSD system detects a drive with Adaptec RAID controller meta > data on it, the ataraid() driver will attempt to interpret that data as > a real volume. It makes no difference to the ataraid() driver if there > is an Adaptec controller physically present in the system or not. > > I.e. if you insert a drive that was part of a volume from an Adaptec > RAID controller into another system, the new system will attempt to > treat that disk as though it were associated with a HOST Raid controller. > > I don't think that this is the desired behavior. Even if the host raid > meta-data is detected, the system shouldn't attempt to treat the disk as > part of a HOST raid set without the appropriate controller in the system. The system should not even be looking at data on a drive unless a command tells it to. Just because a drive has bits on it that happen to look like Adaptec/LSI/whoever RAID metadata doesn't mean that those bits actually *are* RAID metadata, and even if they are, it doesn't mean that the sysadmin wants that disk to be part of a RAID. From sbruno at miralink.com Tue Sep 23 16:48:27 2008 From: sbruno at miralink.com (Sean Bruno) Date: Tue Sep 23 16:48:32 2008 Subject: [RELENG_6] ATARAID oddity In-Reply-To: References: <200809222203.WAA20882@sopwith.solgatos.com> <48D82921.3010904@miralink.com> <48D8572B.3060204@miralink.com> Message-ID: <48D91DDA.9060608@miralink.com> S?ren Schmidt wrote: > Hi > > Just the short version: > > Since this is softraids and the different vendors use different chips, > there is no 1 to 1 relation between raid type and controller PCI id. > Its a puzzle you cannot solve without loosing a good percentage of the > systems out there. > > -S?ren > Agreed. It is very easy to lose systems where the host raid configurations are working. In order to make it easier, I looked over at Heinz's Linux dmraid app. http://people.redhat.com/~heinzm/sw/dmraid/src/ In the Adaptec format, he is looking at PCI ID 0x9005 . The code apparently used to look at 0x9004 as well, but that is commented out at this time. 0x1044 is actually the old dpt() driver PCI ID, so that was completely wrong. I have one of these RAID controllers, and I find it interesting that they use the same RAID metadata. Sean -------------- next part -------------- Index: ata-pci.c =================================================================== --- ata-pci.c (revision 5956) +++ ata-pci.c (working copy) @@ -532,6 +532,7 @@ switch (pci_get_vendor(dev)) { case ATA_ACARD_ID: return "Acard"; case ATA_ACER_LABS_ID: return "AcerLabs"; + case ATA_ADAPTEC_ID: return "Adaptec"; case ATA_AMD_ID: return "AMD"; case ATA_ATI_ID: return "ATI"; case ATA_CYRIX_ID: return "Cyrix"; Index: ata-raid.c =================================================================== --- ata-raid.c (revision 5956) +++ ata-raid.c (working copy) @@ -1304,6 +1304,12 @@ /* prioritize vendor native metadata layout if possible */ if (devclass == pci_devclass) { switch (pci_get_vendor(GRANDPARENT(device_get_parent(subdisk)))) { + /* Adaptec HostRAID */ + case ATA_ADAPTEC_ID: + if (ata_raid_adaptec_read_meta(subdisk, ata_raid_arrays)) + return 0; + break; + case ATA_HIGHPOINT_ID: if (ata_raid_hptv3_read_meta(subdisk, ata_raid_arrays)) return 0; @@ -1358,10 +1364,6 @@ /* handle controllers that have multiple layout possibilities */ /* NOTE: the order of these are not insignificant */ - /* Adaptec HostRAID */ - if (ata_raid_adaptec_read_meta(subdisk, ata_raid_arrays)) - return 0; - /* LSILogic v3 and v2 */ if (ata_raid_lsiv3_read_meta(subdisk, ata_raid_arrays)) return 0; Index: ata-pci.h =================================================================== --- ata-pci.h (revision 5956) +++ ata-pci.h (working copy) @@ -71,6 +71,8 @@ }; /* defines for known chipset PCI id's */ +#define ATA_ADAPTEC_ID 0x9005 + #define ATA_ACARD_ID 0x1191 #define ATA_ATP850 0x00021191 #define ATA_ATP850A 0x00041191 From sbruno at miralink.com Wed Sep 24 00:45:54 2008 From: sbruno at miralink.com (Sean Bruno) Date: Wed Sep 24 00:45:56 2008 Subject: ATA fails to add new disks (atacontrol reinit) Message-ID: <48D98DC0.6080201@miralink.com> Is it expected that an "atacontrol reinit " won't find new disks but will delete removed disks? Looking over the ata_reinit() / ad_reinit() code, it should be possible to probe and find new drives when userland asks to redetect them. -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Cell 503-358-6832 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com From bu7cher at yandex.ru Wed Sep 24 09:56:47 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Wed Sep 24 09:56:49 2008 Subject: Why some devices cannot be detected? Message-ID: <48DA0A35.9030603@yandex.ru> Hi, All. I don't have this problem, but i saw it in several users reports. System can't detect some devices. Last example (from one report): Windows/Linux detected LSI MegaRAID SAS 8408E RAID Controller on an motherboard, but freebsd didn't detect. pciconf list: hostb0@pci0:0:0:0: class=0x060000 card=0x83361033 chip=0x25d88086 rev=0xb1 hdr=0x00 pcib1@pci0:0:2:0: class=0x060400 card=0x00000000 chip=0x25f78086 rev=0xb1 hdr=0x01 pcib8@pci0:0:3:0: class=0x060400 card=0x00000000 chip=0x25e38086 rev=0xb1 hdr=0x01 pcib9@pci0:0:4:0: class=0x060400 card=0x00000000 chip=0x25f88086 rev=0xb1 hdr=0x01 pcib10@pci0:0:5:0: class=0x060400 card=0x00000000 chip=0x25e58086 rev=0xb1 hdr=0x01 pcib11@pci0:0:6:0: class=0x060400 card=0x00000000 chip=0x25e68086 rev=0xb1 hdr=0x01 pcib12@pci0:0:7:0: class=0x060400 card=0x00000000 chip=0x25e78086 rev=0xb1 hdr=0x01 hostb1@pci0:0:16:0: class=0x060000 card=0x83361033 chip=0x25f08086 rev=0xb1 hdr=0x00 hostb2@pci0:0:16:1: class=0x060000 card=0x83361033 chip=0x25f08086 rev=0xb1 hdr=0x00 hostb3@pci0:0:16:2: class=0x060000 card=0x83361033 chip=0x25f08086 rev=0xb1 hdr=0x00 hostb4@pci0:0:17:0: class=0x060000 card=0x83361033 chip=0x25f18086 rev=0xb1 hdr=0x00 hostb5@pci0:0:19:0: class=0x060000 card=0x83361033 chip=0x25f38086 rev=0xb1 hdr=0x00 hostb6@pci0:0:21:0: class=0x060000 card=0x83361033 chip=0x25f58086 rev=0xb1 hdr=0x00 hostb7@pci0:0:22:0: class=0x060000 card=0x83361033 chip=0x25f68086 rev=0xb1 hdr=0x00 pcib13@pci0:0:28:0: class=0x060400 card=0x83361033 chip=0x26908086 rev=0x09 hdr=0x01 uhci0@pci0:0:29:0: class=0x0c0300 card=0x83361033 chip=0x26888086 rev=0x09 hdr=0x00 uhci1@pci0:0:29:1: class=0x0c0300 card=0x83361033 chip=0x26898086 rev=0x09 hdr=0x00 uhci2@pci0:0:29:2: class=0x0c0300 card=0x83361033 chip=0x268a8086 rev=0x09 hdr=0x00 uhci3@pci0:0:29:3: class=0x0c0300 card=0x83361033 chip=0x268b8086 rev=0x09 hdr=0x00 ehci0@pci0:0:29:7: class=0x0c0320 card=0x83361033 chip=0x268c8086 rev=0x09 hdr=0x00 pcib14@pci0:0:30:0: class=0x060401 card=0x83361033 chip=0x244e8086 rev=0xd9 hdr=0x01 isab0@pci0:0:31:0: class=0x060100 card=0x83361033 chip=0x26708086 rev=0x09 hdr=0x00 atapci0@pci0:0:31:1: class=0x01018a card=0x83361033 chip=0x269e8086 rev=0x09 hdr=0x00 none0@pci0:0:31:3: class=0x0c0500 card=0x83361033 chip=0x269b8086 rev=0x09 hdr=0x00 pcib2@pci0:1:0:0: class=0x060400 card=0x83361033 chip=0x35008086 rev=0x01 hdr=0x01 pcib7@pci0:1:0:3: class=0x060400 card=0x83361033 chip=0x350c8086 rev=0x01 hdr=0x01 pcib3@pci0:2:0:0: class=0x060400 card=0x83361033 chip=0x35108086 rev=0x01 hdr=0x01 pcib6@pci0:2:2:0: class=0x060400 card=0x83361033 chip=0x35188086 rev=0x01 hdr=0x01 pcib4@pci0:3:0:0: class=0x060400 card=0x00000000 chip=0x03708086 rev=0x00 hdr=0x01 pcib5@pci0:3:0:2: class=0x060400 card=0x00000000 chip=0x03728086 rev=0x00 hdr=0x01 em0@pci0:12:0:0: class=0x020000 card=0x83361033 chip=0x10968086 rev=0x01 hdr=0x00 em1@pci0:12:0:1: class=0x020000 card=0x83361033 chip=0x10968086 rev=0x01 hdr=0x00 mpt0@pci0:13:5:0: class=0x010000 card=0x83361033 chip=0x00541000 rev=0x01 hdr=0x00 vgapci0@pci0:36:0:0: class=0x030000 card=0x83361033 chip=0x0522102b rev=0x02 hdr=0x00 Windows detects it as Device Description LSI MegaRAID SAS 8408E RAID Controller Bus Type PCI-X Bus / Device / Function 4 / 14 / 0 Device ID 1000-0411 Subsystem ID 1000-1001 Device Class 0104 (RAID Controller) Revision 00 Fast Back-to-Back Transactions Not Supported Device Features 66 MHz Operation Supported Bus Mastering Enabled PCI-X Device Properties 64-bit Device Yes 133 MHz Operation Supported PCI-X 266 Not Supported PCI-X 533 Not Supported --------------------------------------- So, question is why freebsd can't detect this device? -- WBR, Andrey V. Elsukov From sbruno at miralink.com Wed Sep 24 16:10:51 2008 From: sbruno at miralink.com (Sean Bruno) Date: Wed Sep 24 16:10:53 2008 Subject: Why some devices cannot be detected? In-Reply-To: <48DA0A35.9030603@yandex.ru> References: <48DA0A35.9030603@yandex.ru> Message-ID: <48DA668A.3070400@miralink.com> Andrey V. Elsukov wrote: > Hi, All. > > I don't have this problem, but i saw it in several users reports. > System can't detect some devices. Last example (from one report): > Windows/Linux detected LSI MegaRAID SAS 8408E RAID Controller on > an motherboard, but freebsd didn't detect. > > pciconf list: > hostb0@pci0:0:0:0: class=0x060000 card=0x83361033 chip=0x25d88086 > rev=0xb1 hdr=0x00 > pcib1@pci0:0:2:0: class=0x060400 card=0x00000000 chip=0x25f78086 > rev=0xb1 hdr=0x01 > pcib8@pci0:0:3:0: class=0x060400 card=0x00000000 chip=0x25e38086 > rev=0xb1 hdr=0x01 > pcib9@pci0:0:4:0: class=0x060400 card=0x00000000 chip=0x25f88086 > rev=0xb1 hdr=0x01 > pcib10@pci0:0:5:0: class=0x060400 card=0x00000000 chip=0x25e58086 > rev=0xb1 hdr=0x01 > pcib11@pci0:0:6:0: class=0x060400 card=0x00000000 chip=0x25e68086 > rev=0xb1 hdr=0x01 > pcib12@pci0:0:7:0: class=0x060400 card=0x00000000 chip=0x25e78086 > rev=0xb1 hdr=0x01 > hostb1@pci0:0:16:0: class=0x060000 card=0x83361033 chip=0x25f08086 > rev=0xb1 hdr=0x00 > hostb2@pci0:0:16:1: class=0x060000 card=0x83361033 chip=0x25f08086 > rev=0xb1 hdr=0x00 > hostb3@pci0:0:16:2: class=0x060000 card=0x83361033 chip=0x25f08086 > rev=0xb1 hdr=0x00 > hostb4@pci0:0:17:0: class=0x060000 card=0x83361033 chip=0x25f18086 > rev=0xb1 hdr=0x00 > hostb5@pci0:0:19:0: class=0x060000 card=0x83361033 chip=0x25f38086 > rev=0xb1 hdr=0x00 > hostb6@pci0:0:21:0: class=0x060000 card=0x83361033 chip=0x25f58086 > rev=0xb1 hdr=0x00 > hostb7@pci0:0:22:0: class=0x060000 card=0x83361033 chip=0x25f68086 > rev=0xb1 hdr=0x00 > pcib13@pci0:0:28:0: class=0x060400 card=0x83361033 chip=0x26908086 > rev=0x09 hdr=0x01 > uhci0@pci0:0:29:0: class=0x0c0300 card=0x83361033 chip=0x26888086 > rev=0x09 hdr=0x00 > uhci1@pci0:0:29:1: class=0x0c0300 card=0x83361033 chip=0x26898086 > rev=0x09 hdr=0x00 > uhci2@pci0:0:29:2: class=0x0c0300 card=0x83361033 chip=0x268a8086 > rev=0x09 hdr=0x00 > uhci3@pci0:0:29:3: class=0x0c0300 card=0x83361033 chip=0x268b8086 > rev=0x09 hdr=0x00 > ehci0@pci0:0:29:7: class=0x0c0320 card=0x83361033 chip=0x268c8086 > rev=0x09 hdr=0x00 > pcib14@pci0:0:30:0: class=0x060401 card=0x83361033 chip=0x244e8086 > rev=0xd9 hdr=0x01 > isab0@pci0:0:31:0: class=0x060100 card=0x83361033 chip=0x26708086 > rev=0x09 hdr=0x00 > atapci0@pci0:0:31:1: class=0x01018a card=0x83361033 chip=0x269e8086 > rev=0x09 hdr=0x00 > none0@pci0:0:31:3: class=0x0c0500 card=0x83361033 chip=0x269b8086 > rev=0x09 hdr=0x00 > pcib2@pci0:1:0:0: class=0x060400 card=0x83361033 chip=0x35008086 > rev=0x01 hdr=0x01 > pcib7@pci0:1:0:3: class=0x060400 card=0x83361033 chip=0x350c8086 > rev=0x01 hdr=0x01 > pcib3@pci0:2:0:0: class=0x060400 card=0x83361033 chip=0x35108086 > rev=0x01 hdr=0x01 > pcib6@pci0:2:2:0: class=0x060400 card=0x83361033 chip=0x35188086 > rev=0x01 hdr=0x01 > pcib4@pci0:3:0:0: class=0x060400 card=0x00000000 chip=0x03708086 > rev=0x00 hdr=0x01 > pcib5@pci0:3:0:2: class=0x060400 card=0x00000000 chip=0x03728086 > rev=0x00 hdr=0x01 > em0@pci0:12:0:0: class=0x020000 card=0x83361033 chip=0x10968086 > rev=0x01 hdr=0x00 > em1@pci0:12:0:1: class=0x020000 card=0x83361033 chip=0x10968086 > rev=0x01 hdr=0x00 > mpt0@pci0:13:5:0: class=0x010000 card=0x83361033 chip=0x00541000 > rev=0x01 hdr=0x00 > vgapci0@pci0:36:0:0: class=0x030000 card=0x83361033 chip=0x0522102b > rev=0x02 hdr=0x00 > > Windows detects it as > > Device Description LSI MegaRAID SAS 8408E RAID Controller > Bus Type PCI-X > Bus / Device / Function 4 / 14 / 0 > Device ID 1000-0411 > Subsystem ID 1000-1001 > Device Class 0104 (RAID Controller) > Revision 00 > Fast Back-to-Back Transactions Not Supported > > Device Features > 66 MHz Operation Supported > Bus Mastering Enabled > > PCI-X Device Properties > 64-bit Device Yes > 133 MHz Operation Supported > PCI-X 266 Not Supported > PCI-X 533 Not Supported > --------------------------------------- > > So, question is why freebsd can't detect this device? > Is this the adapter? mpt0@pci0:13:5:0: class=0x010000 card=0x83361033 chip=0x00541000 rev=0x01 hdr=0x00 Because it looks like it was detected. -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com From jhb at freebsd.org Wed Sep 24 16:54:51 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Sep 24 16:54:58 2008 Subject: Why some devices cannot be detected? In-Reply-To: <48DA0A35.9030603@yandex.ru> References: <48DA0A35.9030603@yandex.ru> Message-ID: <200809241152.41761.jhb@freebsd.org> On Wednesday 24 September 2008 05:36:53 am Andrey V. Elsukov wrote: > Hi, All. > > I don't have this problem, but i saw it in several users reports. > System can't detect some devices. Last example (from one report): > Windows/Linux detected LSI MegaRAID SAS 8408E RAID Controller on > an motherboard, but freebsd didn't detect. > > pciconf list: > hostb0@pci0:0:0:0: class=0x060000 card=0x83361033 chip=0x25d88086 > rev=0xb1 hdr=0x00 > pcib1@pci0:0:2:0: class=0x060400 card=0x00000000 chip=0x25f78086 > rev=0xb1 hdr=0x01 > pcib8@pci0:0:3:0: class=0x060400 card=0x00000000 chip=0x25e38086 > rev=0xb1 hdr=0x01 > pcib9@pci0:0:4:0: class=0x060400 card=0x00000000 chip=0x25f88086 > rev=0xb1 hdr=0x01 > pcib10@pci0:0:5:0: class=0x060400 card=0x00000000 chip=0x25e58086 > rev=0xb1 hdr=0x01 > pcib11@pci0:0:6:0: class=0x060400 card=0x00000000 chip=0x25e68086 > rev=0xb1 hdr=0x01 > pcib12@pci0:0:7:0: class=0x060400 card=0x00000000 chip=0x25e78086 > rev=0xb1 hdr=0x01 > hostb1@pci0:0:16:0: class=0x060000 card=0x83361033 chip=0x25f08086 > rev=0xb1 hdr=0x00 > hostb2@pci0:0:16:1: class=0x060000 card=0x83361033 chip=0x25f08086 > rev=0xb1 hdr=0x00 > hostb3@pci0:0:16:2: class=0x060000 card=0x83361033 chip=0x25f08086 > rev=0xb1 hdr=0x00 > hostb4@pci0:0:17:0: class=0x060000 card=0x83361033 chip=0x25f18086 > rev=0xb1 hdr=0x00 > hostb5@pci0:0:19:0: class=0x060000 card=0x83361033 chip=0x25f38086 > rev=0xb1 hdr=0x00 > hostb6@pci0:0:21:0: class=0x060000 card=0x83361033 chip=0x25f58086 > rev=0xb1 hdr=0x00 > hostb7@pci0:0:22:0: class=0x060000 card=0x83361033 chip=0x25f68086 > rev=0xb1 hdr=0x00 > pcib13@pci0:0:28:0: class=0x060400 card=0x83361033 chip=0x26908086 > rev=0x09 hdr=0x01 > uhci0@pci0:0:29:0: class=0x0c0300 card=0x83361033 chip=0x26888086 > rev=0x09 hdr=0x00 > uhci1@pci0:0:29:1: class=0x0c0300 card=0x83361033 chip=0x26898086 > rev=0x09 hdr=0x00 > uhci2@pci0:0:29:2: class=0x0c0300 card=0x83361033 chip=0x268a8086 > rev=0x09 hdr=0x00 > uhci3@pci0:0:29:3: class=0x0c0300 card=0x83361033 chip=0x268b8086 > rev=0x09 hdr=0x00 > ehci0@pci0:0:29:7: class=0x0c0320 card=0x83361033 chip=0x268c8086 > rev=0x09 hdr=0x00 > pcib14@pci0:0:30:0: class=0x060401 card=0x83361033 chip=0x244e8086 > rev=0xd9 hdr=0x01 > isab0@pci0:0:31:0: class=0x060100 card=0x83361033 chip=0x26708086 > rev=0x09 hdr=0x00 > atapci0@pci0:0:31:1: class=0x01018a card=0x83361033 chip=0x269e8086 > rev=0x09 hdr=0x00 > none0@pci0:0:31:3: class=0x0c0500 card=0x83361033 chip=0x269b8086 > rev=0x09 hdr=0x00 > pcib2@pci0:1:0:0: class=0x060400 card=0x83361033 chip=0x35008086 > rev=0x01 hdr=0x01 > pcib7@pci0:1:0:3: class=0x060400 card=0x83361033 chip=0x350c8086 > rev=0x01 hdr=0x01 > pcib3@pci0:2:0:0: class=0x060400 card=0x83361033 chip=0x35108086 > rev=0x01 hdr=0x01 > pcib6@pci0:2:2:0: class=0x060400 card=0x83361033 chip=0x35188086 > rev=0x01 hdr=0x01 > pcib4@pci0:3:0:0: class=0x060400 card=0x00000000 chip=0x03708086 > rev=0x00 hdr=0x01 > pcib5@pci0:3:0:2: class=0x060400 card=0x00000000 chip=0x03728086 > rev=0x00 hdr=0x01 > em0@pci0:12:0:0: class=0x020000 card=0x83361033 chip=0x10968086 > rev=0x01 hdr=0x00 > em1@pci0:12:0:1: class=0x020000 card=0x83361033 chip=0x10968086 > rev=0x01 hdr=0x00 > mpt0@pci0:13:5:0: class=0x010000 card=0x83361033 chip=0x00541000 > rev=0x01 hdr=0x00 > vgapci0@pci0:36:0:0: class=0x030000 card=0x83361033 chip=0x0522102b > rev=0x02 hdr=0x00 > > Windows detects it as > > Device Description LSI MegaRAID SAS 8408E RAID Controller > Bus Type PCI-X > Bus / Device / Function 4 / 14 / 0 > Device ID 1000-0411 > Subsystem ID 1000-1001 > Device Class 0104 (RAID Controller) > Revision 00 > Fast Back-to-Back Transactions Not Supported > > Device Features > 66 MHz Operation Supported > Bus Mastering Enabled > > PCI-X Device Properties > 64-bit Device Yes > 133 MHz Operation Supported > PCI-X 266 Not Supported > PCI-X 533 Not Supported > --------------------------------------- > > So, question is why freebsd can't detect this device? FreeBSD didn't see a PCI bus 4. Can you determine from another OS if PCI bus 4 is attached to a Host-PCI bridge or a PCI-PCI bridge? -- John Baldwin From Satendra.Pratap at citrix.com Thu Sep 25 07:41:49 2008 From: Satendra.Pratap at citrix.com (Satendra Pratap) Date: Thu Sep 25 07:41:56 2008 Subject: regarding 1 Gig Chelsio SFP support Message-ID: Hello , I am new to FreeBSD and recently joined this mailing list. I hope that I am sending my question on the correct mailing list. We have chelsio T304 1 Gig card which supports Fiber SFP. I have already asked from chelsio guys for its Driver support on FreeBSD and still waiting for reply. Just wondering if anybody could let me know about T304's Driver support on FreeBSD. One more question, because we use third party SFPs (finsar, picolight etc) so do we need to download SFP's drivers also or NIC vendor's device driver should already have that support? Thanks, Satendra From unixmania at gmail.com Thu Sep 25 12:12:57 2008 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Thu Sep 25 12:13:03 2008 Subject: regarding 1 Gig Chelsio SFP support In-Reply-To: References: Message-ID: On Thu, Sep 25, 2008 at 4:13 AM, Satendra Pratap wrote: --8<--- > We have chelsio T304 1 Gig card which supports Fiber SFP. I have already > asked from chelsio guys for its Driver support on FreeBSD and still > waiting for reply. Just wondering if anybody could let me know about > T304's Driver support on FreeBSD. > > One more question, because we use third party SFPs (finsar, picolight > etc) so do we need to download SFP's drivers also or NIC vendor's > device driver should already have that support? Kip Macy is the maintainer of drivers for some Chelsio hardware. If you are attempting to use the hardware on FreeBSD 6.x of 7.x then ask in the freebsd-stable mailing list, otherwise ask in freebsd-current. -- cd /usr/ports/sysutils/life make clean