From owner-freebsd-scsi Sun Jun 11 23:29:24 2000 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 8395637BAD1 for ; Sun, 11 Jun 2000 23:29:20 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id AAA10869; Mon, 12 Jun 2000 00:29:12 -0600 (MDT) (envelope-from ken) Date: Mon, 12 Jun 2000 00:29:12 -0600 From: "Kenneth D. Merry" To: Fanying Jen Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Need Help with Dual Machines with One Shared SCSI RAID Message-ID: <20000612002912.A10824@panzer.kdm.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from fanying@fynet.com on Fri, Jun 09, 2000 at 01:32:06PM -0400 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jun 09, 2000 at 13:32:06 -0400, Fanying Jen wrote: > I am trying to break from Linux for the first time and in a big way. I > have two 486s > > fanying.fynet.com > cindy.fynet.com > > which have identical processors, motherboards, memory, controllers, > video, and even cases. The two machines shared via scsi a single > external box with a disk array. The disk array is 4 disk in quantity and > of the type UW SCSI, not U2W SCSI, and of the SE type. The drives are of > identical make and model, Western Digital 9100-0007. The diagram shows > the setup below: [ two machines connected to one RAID array ] > Machine specs: > > fanying.fynet.com & cindy.fynet.com > > 486DX-33 > 128MB ea > Amptron DX-9700 > Adaptec 2940UW > SCSI CDROM > Intel Intelligence Server Ethernet (i960) -> nice Have you checked to see whether that adapter is supported? The generic 8255[7-9] Intel chips are supported, but I dunno about their adapters with onboard i960's. > 3Com 3c509B > No internal hard disks, all of them are in the scsi box. > > What I am trying to do with FreeBSD is to set up a cluster with RAID-1 > and RAID-5. Both machines will boot up from the external disk drives. My > questions is how I set up the partitions to allow the disk to appear the > same to both machines and does FreeBSD support mandatory file locking > which means that any and all files that are being written to are lock > for the other machines? I need help with this. I see plenty of > documentation for Linux but my friend at www.saturated.net (FreeBSD Fan) > says that FreeBSD is more efficient especially for a machine like mine > and I want to be able to use FreeBSD for a Cluster with a Shared RAID > SCSI storage. At the moment FreeBSD doesn't support read/write mounting of non-network-attached (i.e. filesystems mounted via SCSI, FC, IDE, etc.) filesystems by multiple machines. Well, you can do it, but you'll most likely end up with the contents of the filesystem scrambled, since you'll have two machines writing to it at the same time. If you want a setup like that, the only safe way to do it would be if both machines mounted the RAID array read-only. You might want to search the freebsd-scsi list archives for a thread that took place in late April, the subject line was: "Safe mounting of one file system on multiple hosts?" There was a little bit of discussion about mounting a disk array on multiple machines. 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 Jun 12 23:49:50 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from hermes.mixx.net (hermes.mixx.net [212.84.196.2]) by hub.freebsd.org (Postfix) with ESMTP id 16BDE37B505 for ; Mon, 12 Jun 2000 23:49:33 -0700 (PDT) (envelope-from graichen@innominate.de) Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 35C8FF808; Tue, 13 Jun 2000 08:49:31 +0200 (CEST) Received: from h2o.bln.innominate.de (h2o.bln.innominate.de [10.0.0.69]) by mate.bln.innominate.de (Postfix) with ESMTP id C4F0A2CA6B; Tue, 13 Jun 2000 08:49:29 +0200 (CEST) Received: from localhost (graichen@localhost) by h2o.bln.innominate.de (8.9.3/8.9.3) with ESMTP id IAA05746; Tue, 13 Jun 2000 08:49:48 +0200 X-Authentication-Warning: h2o.bln.innominate.de: graichen owned process doing -bs Date: Tue, 13 Jun 2000 08:49:48 +0200 (CEST) From: Thomas Graichen X-Sender: graichen@h2o.bln.innominate.de Reply-To: thomas.graichen@innominate.de To: Takefumi SAYO Cc: tech@ioiscsi.com, scsi@FreeBSD.org Subject: Re: Initio INIC-941 PCI SCSI driver for FreeBSD 4.0-RELEASE In-Reply-To: <20000611013840D.stake@po.shiojiri.ne.jp> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="673024-1863453750-960878988=:5729" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --673024-1863453750-960878988=:5729 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 11 Jun 2000, Takefumi SAYO wrote: > Hello, graichen and IOI Technology Corporation developers. > > I got 'iha-991210.tar.gz' from graichen's web page > (http://www.innominate.org/~tgr/) and modified to fit > FreeBSD 4.0-RELEASE. It seems to work, but complains > that > > iha0: driver is using old-style compatability shims > this comes from the fact that the driver is not yet "newbusified" for that you may look into the mailinglists - i think there was something in them about documenting how to newbusify a driver in the last weeks - i'll attach the newbusify diff for the amd and advansys scsi drivers which i once saved from the liste in order to have a sample for the initio driver maybe they help you as a startingpoint because i have absolutely no time for this right now - please keep me informed if you get anything done in this di- rection (i also may test the a100 driver - ihb) > and > > (cd0:iha0:0:6:0): got CAM status 0xb > (cd0:iha0:0:6:0): fatal error, failed to attach to device > (cd0:iha0:0:6:0): lost device > (cd0:iha0:0:6:0): removing device entry > > if no media presents in the removable device. > > Could you fix this if you have time? Because I don't know > anything about SCSI and CAM. :-( > i don't know much more either :-) ... but i think you may ask this on the scsi list (i'll cc this mail to it too) - maybe someone there might help ... in general my impression is that the initio scsi driver for FreeBSD is not coded very well (i for instance had problems with it and a tape changer) but maybe the above message is even ok (havent seen any scsi cdrom messages for a long time) maybe some more words about the initio driver: i currently have absolutely no time to further work on this - so it would be really fine if anyone might find the time to get this going ... i may test it - i have both conteollers here - one a100 and one 9100u ... also if someone is working on it i may give the password for the initio entry in the bsd driver database to this person a lot of thanks in advance > P.S. > I thank IOI for making driver source code open. :-) at least better than nothing :-) t -- thomas.graichen@innominate.de innominate AG networking people fon: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tg --673024-1863453750-960878988=:5729 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="amd.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: amd newbusify diff Content-Disposition: attachment; filename="amd.diff" SW5kZXg6IHN5cy9wY2kvYW1kLmMNCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N ClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMvcGNpL2FtZC5jLHYNCnJl dHJpZXZpbmcgcmV2aXNpb24gMS41DQpkaWZmIC11IC1yMS41IGFtZC5jDQot LS0gc3lzL3BjaS9hbWQuYwkyMDAwLzAzLzI3IDIwOjIzOjU4CTEuNQ0KKysr IHN5cy9wY2kvYW1kLmMJMjAwMC8wMy8zMSAwOTo1NzoyNw0KQEAgLTYxLDEy ICs2MSwxMiBAQA0KICNpbmNsdWRlIDx2bS92bS5oPg0KICNpbmNsdWRlIDx2 bS9wbWFwLmg+DQogDQotI2luY2x1ZGUgPHBjaS9wY2l2YXIuaD4NCi0jaW5j bHVkZSA8cGNpL3BjaXJlZy5oPg0KLQ0KICNpbmNsdWRlIDxtYWNoaW5lL2J1 c19waW8uaD4NCiAjaW5jbHVkZSA8bWFjaGluZS9idXMuaD4NCiAjaW5jbHVk ZSA8bWFjaGluZS9jbG9jay5oPg0KKyNpbmNsdWRlIDxtYWNoaW5lL3Jlc291 cmNlLmg+DQorI2luY2x1ZGUgPHN5cy9idXMuaD4NCisjaW5jbHVkZSA8c3lz L3JtYW4uaD4NCiANCiAjaW5jbHVkZSA8Y2FtL2NhbS5oPg0KICNpbmNsdWRl IDxjYW0vY2FtX2NjYi5oPg0KQEAgLTc3LDEyICs3NywxMCBAQA0KICNpbmNs dWRlIDxjYW0vc2NzaS9zY3NpX2FsbC5oPg0KICNpbmNsdWRlIDxjYW0vc2Nz aS9zY3NpX21lc3NhZ2UuaD4NCiANCisjaW5jbHVkZSA8cGNpL3BjaXZhci5o Pg0KKyNpbmNsdWRlIDxwY2kvcGNpcmVnLmg+DQogI2luY2x1ZGUgPHBjaS9h bWQuaD4NCiANCi0jaWZuZGVmIENPTVBBVF9PTERQQ0kNCi0jZXJyb3IgIlRo ZSBhbWQgZGV2aWNlIHJlcXVpcmVzIHRoZSBvbGQgcGNpIGNvbXBhdGliaWxp dHkgc2hpbXMiDQotI2VuZGlmDQotDQogI2RlZmluZSBQQ0lfREVWSUNFX0lE X0FNRDUzQzk3NCAJMHgyMDIwMTAyMnVsDQogI2RlZmluZSBQQ0lfQkFTRV9B RERSMAkgICAgCQkweDEwDQogDQpAQCAtMTI4LDggKzEyNiw3IEBADQogc3Rh dGljIHVfaW50OF90ICogcGh5c3RvdmlydChzdHJ1Y3QgYW1kX3NyYiAqcFNS QiwgdV9pbnQzMl90IHhmZXJDbnQpOw0KIA0KIHZvaWQgICAgYW1kX2xpbmtT UkIoc3RydWN0IGFtZF9zb2Z0YyAqYW1kKTsNCi1zdGF0aWMgc3RydWN0IGFt ZF9zb2Z0YyAqDQotCWFtZF9pbml0KGludCB1bml0LCBwY2ljaV90IGNvbmZp Z19pZCk7DQorc3RhdGljIGludCBhbWRfaW5pdChkZXZpY2VfdCk7DQogc3Rh dGljIHZvaWQgYW1kX2xvYWRfZGVmYXVsdHMoc3RydWN0IGFtZF9zb2Z0YyAq YW1kKTsNCiBzdGF0aWMgdm9pZCBhbWRfbG9hZF9lZXByb21fb3JfZGVmYXVs dHMoc3RydWN0IGFtZF9zb2Z0YyAqYW1kKTsNCiBzdGF0aWMgaW50IGFtZF9F RXByb21JbkRPKHN0cnVjdCBhbWRfc29mdGMgKmFtZCk7DQpAQCAtMTM5LDgg KzEzNiw4IEBADQogc3RhdGljIHZvaWQgYW1kX1ByZXBhcmUoc3RydWN0IGFt ZF9zb2Z0YyAqYW1kLCBpbnQgKnJlZ3ZhbCwgdV9pbnQ4X3QgRUVwcm9tQ21k KTsNCiBzdGF0aWMgdm9pZCBhbWRfUmVhZEVFcHJvbShzdHJ1Y3QgYW1kX3Nv ZnRjICphbWQpOw0KIA0KLXN0YXRpYyBjb25zdCBjaGFyICphbWRfcHJvYmUo cGNpY2lfdCB0YWcsIHBjaWRpX3QgdHlwZSk7DQotc3RhdGljIHZvaWQgYW1k X2F0dGFjaChwY2ljaV90IHRhZywgaW50IHVuaXQpOw0KK3N0YXRpYyBpbnQg YW1kX3Byb2JlKGRldmljZV90KTsNCitzdGF0aWMgaW50IGFtZF9hdHRhY2go ZGV2aWNlX3QpOw0KIHN0YXRpYyB2b2lkIGFtZGNvbXBsZXRlbWF0Y2goc3Ry dWN0IGFtZF9zb2Z0YyAqYW1kLCB0YXJnZXRfaWRfdCB0YXJnZXQsDQogCQkJ ICAgICBsdW5faWRfdCBsdW4sIHVfaW50IHRhZywgc3RydWN0IHNyYl9xdWV1 ZSAqcXVldWUsDQogCQkJICAgICBjYW1fc3RhdHVzIHN0YXR1cyk7DQpAQCAt MTU4LDggKzE1NSw2IEBADQogCWFtZC0+bXNnaW5faW5kZXggPSAwOw0KIH0N CiANCi1zdGF0aWMgdV9sb25nIGFtZF9jb3VudDsNCi0NCiAvKiBDQU0gU0lN IGVudHJ5IHBvaW50cyAqLw0KICNkZWZpbmUgY2NiX3NyYl9wdHIgc3ByaXZf cHRyMA0KICNkZWZpbmUgY2NiX2FtZF9wdHIgc3ByaXZfcHRyMQ0KQEAgLTE2 NywyNCArMTYyLDYgQEANCiBzdGF0aWMgdm9pZAlhbWRfcG9sbChzdHJ1Y3Qg Y2FtX3NpbSAqc2ltKTsNCiANCiAvKg0KLSAqIFBDSSBkZXZpY2UgbW9kdWxl IHNldHVwDQotICovDQotc3RhdGljIHN0cnVjdCBwY2lfZGV2aWNlIGFtZF9k ZXZpY2UgPQ0KLXsNCi0JImFtZCIsDQotCWFtZF9wcm9iZSwNCi0JYW1kX2F0 dGFjaCwNCi0JJmFtZF9jb3VudCwNCi0JTlVMTA0KLX07DQotDQotI2lmZGVm IENPTVBBVF9QQ0lfRFJJVkVSDQotQ09NUEFUX1BDSV9EUklWRVIoYW1kLCBh bWRfZGV2aWNlKTsNCi0jZWxzZQ0KLURBVEFfU0VUKHBjaWRldmljZV9zZXQs IGFtZF9kZXZpY2UpOw0KLSNlbmRpZg0KLQ0KLS8qDQogICogU3RhdGUgZW5n aW5lIGZ1bmN0aW9uIHRhYmxlcyBpbmRleGVkIGJ5IFNDU0kgcGhhc2UgbnVt YmVyDQogICovDQogcGhhc2VfaGFuZGxlcl9mdW5jX3QgYW1kX1NDU0lfcGhh c2UwW10gPSB7DQpAQCAtMjEzOCw5ICsyMTE1LDkgQEANCiAJfSBlbHNlIHsN CiAJCSpyZWd2YWwgPSAweDgwOw0KIAl9DQotCXBjaV9jZmd3cml0ZShhbWQt PmNvbmZpZ19pZCwgKnJlZ3ZhbCwgMCwgLypieXRlcyovMSk7DQorCXBjaV93 cml0ZV9jb25maWcoYW1kLT5kZXYsICpyZWd2YWwsIDAsIC8qYnl0ZXMqLzEp Ow0KIAlpZiAobW9kZSA9PSBESVNBQkxFX0NFKSB7DQotCQlwY2lfY2Znd3Jp dGUoYW1kLT5jb25maWdfaWQsICpyZWd2YWwsIDAsIC8qYnl0ZXMqLzEpOw0K KwkJcGNpX3dyaXRlX2NvbmZpZyhhbWQtPmRldiwgKnJlZ3ZhbCwgMCwgLypi eXRlcyovMSk7DQogCX0NCiAJREVMQVkoMTYwKTsNCiB9DQpAQCAtMjE1NCwy NCArMjEzMSwyNCBAQA0KIAlpZiAoQ2FycnkpIHsNCiAJCWJ2YWwgPSAweDQw Ow0KIAkJKnJlZ3ZhbCA9IDB4ODA7DQotCQlwY2lfY2Znd3JpdGUoYW1kLT5j b25maWdfaWQsICpyZWd2YWwsIGJ2YWwsIC8qYnl0ZXMqLzEpOw0KKwkJcGNp X3dyaXRlX2NvbmZpZyhhbWQtPmRldiwgKnJlZ3ZhbCwgYnZhbCwgLypieXRl cyovMSk7DQogCX0NCiAJREVMQVkoMTYwKTsNCiAJYnZhbCB8PSAweDgwOw0K LQlwY2lfY2Znd3JpdGUoYW1kLT5jb25maWdfaWQsICpyZWd2YWwsIGJ2YWws IC8qYnl0ZXMqLzEpOw0KKwlwY2lfd3JpdGVfY29uZmlnKGFtZC0+ZGV2LCAq cmVndmFsLCBidmFsLCAvKmJ5dGVzKi8xKTsNCiAJREVMQVkoMTYwKTsNCi0J cGNpX2NmZ3dyaXRlKGFtZC0+Y29uZmlnX2lkLCAqcmVndmFsLCAwLCAvKmJ5 dGVzKi8xKTsNCisJcGNpX3dyaXRlX2NvbmZpZyhhbWQtPmRldiwgKnJlZ3Zh bCwgMCwgLypieXRlcyovMSk7DQogCURFTEFZKDE2MCk7DQogfQ0KIA0KIHN0 YXRpYyBpbnQNCiBhbWRfRUVwcm9tSW5ETyhzdHJ1Y3QgYW1kX3NvZnRjICph bWQpDQogew0KLQlwY2lfY2Znd3JpdGUoYW1kLT5jb25maWdfaWQsIDB4ODAs IDB4ODAsIC8qYnl0ZXMqLzEpOw0KKwlwY2lfd3JpdGVfY29uZmlnKGFtZC0+ ZGV2LCAweDgwLCAweDgwLCAvKmJ5dGVzKi8xKTsNCiAJREVMQVkoMTYwKTsN Ci0JcGNpX2NmZ3dyaXRlKGFtZC0+Y29uZmlnX2lkLCAweDgwLCAweDQwLCAv KmJ5dGVzKi8xKTsNCisJcGNpX3dyaXRlX2NvbmZpZyhhbWQtPmRldiwgMHg4 MCwgMHg0MCwgLypieXRlcyovMSk7DQogCURFTEFZKDE2MCk7DQotCWlmIChw Y2lfY2ZncmVhZChhbWQtPmNvbmZpZ19pZCwgMCwgLypieXRlcyovMSkgPT0g MHgyMikNCisJaWYgKHBjaV9yZWFkX2NvbmZpZyhhbWQtPmRldiwgMCwgLypi eXRlcyovMSkgPT0gMHgyMikNCiAJCXJldHVybiAoMSk7DQogCXJldHVybiAo MCk7DQogfQ0KQEAgLTIyNjksMjIgKzIyNDYsMjEgQEANCiAgKiBJbnB1dHMg ICAgICAgIDogaG9zdCAtIHBvaW50ZXIgdG8gdGhpcyBob3N0IGFkYXB0ZXIn cyBzdHJ1Y3R1cmUvDQogICoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCiAg Ki8NCi1zdGF0aWMgc3RydWN0IGFtZF9zb2Z0YyAqDQotYW1kX2luaXQoaW50 IHVuaXQsIHBjaWNpX3QgY29uZmlnX2lkKQ0KK3N0YXRpYyBpbnQNCithbWRf aW5pdChkZXZpY2VfdCBkZXYpDQogew0KLQlzdHJ1Y3QgYW1kX3NvZnRjICph bWQ7DQotCXVfaW50ICBidmFsOw0KLQl1X2ludCAgaTsNCisJc3RydWN0IGFt ZF9zb2Z0YyAqYW1kID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOw0KKwlzdHJ1 Y3QgcmVzb3VyY2UJKmlvcmVzOw0KKwlpbnQJaSwgcmlkID0gMDsNCisJdV9p bnQJYnZhbDsNCisNCisJaW9yZXMgPSBidXNfYWxsb2NfcmVzb3VyY2UoZGV2 LCBTWVNfUkVTX0lPUE9SVCwgJnJpZCwgMCwgfjAsIDEsDQorCQkJCSAgIFJG X0FDVElWRSk7DQorCWlmIChpb3JlcyA9PSBOVUxMKQ0KKwkJcmV0dXJuIEVO WElPOw0KKwlhbWQtPnRhZyA9IHJtYW5fZ2V0X2J1c3RhZyhpb3Jlcyk7DQor CWFtZC0+YnNoID0gcm1hbl9nZXRfYnVzaGFuZGxlKGlvcmVzKTsNCiANCi0J YW1kID0gKHN0cnVjdCBhbWRfc29mdGMgKiltYWxsb2Moc2l6ZW9mKHN0cnVj dCBhbWRfc29mdGMpLA0KLQkJCQkJIE1fREVWQlVGLCBNX1dBSVRPSyk7DQot CWlmIChhbWQgPT0gTlVMTCkgew0KLQkJcHJpbnRmKCJEQzM5MCVkOiBjYW5u b3QgYWxsb2NhdGUgQUNCICFcbiIsIHVuaXQpOw0KLQkJcmV0dXJuIChhbWQp Ow0KLQl9DQotCWJ6ZXJvKGFtZCwgc2l6ZW9mKHN0cnVjdCBhbWRfc29mdGMp KTsNCi0JYW1kLT50YWcgPSBJMzg2X0JVU19TUEFDRV9JTzsNCi0JYW1kLT5i c2ggPSBwY2lfY29uZl9yZWFkKGNvbmZpZ19pZCwgUENJX01BUF9SRUdfU1RB UlQpICYgMHhGRkZFOw0KIAkvKiBETUEgdGFnIGZvciBtYXBwaW5nIGJ1ZmZl cnMgaW50byBkZXZpY2UgdmlzaWJsZSBzcGFjZS4gKi8NCiAJaWYgKGJ1c19k bWFfdGFnX2NyZWF0ZSgvKnBhcmVudF9kbWF0Ki9OVUxMLCAvKmFsaWdubWVu dCovMSwNCiAJCQkgICAgICAgLypib3VuZGFyeSovMCwNCkBAIC0yMjk1LDE1 ICsyMjcxLDE0IEBADQogCQkJICAgICAgIC8qbWF4c2Vnc3oqL0FNRF9NQVhU UkFOU0ZFUl9TSVpFLA0KIAkJCSAgICAgICAvKmZsYWdzKi9CVVNfRE1BX0FM TE9DTk9XLA0KIAkJCSAgICAgICAmYW1kLT5idWZmZXJfZG1hdCkgIT0gMCkg ew0KLQkJZnJlZShhbWQsIE1fREVWQlVGKTsNCi0gICAgICAgICAgICAgICAg cmV0dXJuIChOVUxMKTsNCisJCXJldHVybiBFTlhJTzsNCiAgICAgICAgIH0N CiAJVEFJTFFfSU5JVCgmYW1kLT5mcmVlX3NyYnMpOw0KIAlUQUlMUV9JTklU KCZhbWQtPnJ1bm5pbmdfc3Jicyk7DQogCVRBSUxRX0lOSVQoJmFtZC0+d2Fp dGluZ19zcmJzKTsNCiAJYW1kLT5sYXN0X3BoYXNlID0gU0NTSV9CVVNfRlJF RTsNCi0JYW1kLT5jb25maWdfaWQgPSBjb25maWdfaWQ7DQotCWFtZC0+dW5p dCA9IHVuaXQ7DQorCWFtZC0+ZGV2ID0gZGV2Ow0KKwlhbWQtPnVuaXQgPSBk ZXZpY2VfZ2V0X3VuaXQoZGV2KTsNCiAJYW1kLT5TUkJDb3VudCA9IE1BWF9T UkJfQ05UOw0KIAlhbWQtPnN0YXR1cyA9IDA7DQogCWFtZF9sb2FkX2VlcHJv bV9vcl9kZWZhdWx0cyhhbWQpOw0KQEAgLTIzNjIsMzcgKzIzMzcsMzkgQEAN CiANCiAJLyogRGlzYWJsZSBTQ1NJIGJ1cyByZXNldCBpbnRlcnJ1cHQgKi8N CiAJYW1kX3dyaXRlOChhbWQsIENOVExSRUcxLCBESVNfSU5UX09OX1NDU0lf UlNUKTsNCi0JcmV0dXJuIChhbWQpOw0KKw0KKwlyZXR1cm4gMDsNCiB9DQog DQogLyoNCiAgKiBhdHRhY2ggYW5kIGluaXQgYSBob3N0IGFkYXB0ZXINCiAg Ki8NCi1zdGF0aWMgdm9pZA0KLWFtZF9hdHRhY2gocGNpY2lfdCBjb25maWdf aWQsIGludCB1bml0KQ0KK3N0YXRpYyBpbnQNCithbWRfYXR0YWNoKGRldmlj ZV90IGRldikNCiB7DQotCXN0cnVjdCBjYW1fZGV2cSAqZGV2cTsJLyogRGV2 aWNlIFF1ZXVlIHRvIHVzZSBmb3IgdGhpcyBTSU0gKi8NCi0JdV9pbnQ4X3Qg ICBpbnRzdGF0Ow0KLQl1X2ludDMyX3QgIHdsdmFsOw0KLQlzdHJ1Y3QgYW1k X3NvZnRjICphbWQgPSBOVUxMOw0KKwlzdHJ1Y3QgY2FtX2RldnEJKmRldnE7 CS8qIERldmljZSBRdWV1ZSB0byB1c2UgZm9yIHRoaXMgU0lNICovDQorCXVf aW50OF90CWludHN0YXQ7DQorCXN0cnVjdCBhbWRfc29mdGMgKmFtZCA9IGRl dmljZV9nZXRfc29mdGMoZGV2KTsNCisJaW50CQl1bml0ID0gZGV2aWNlX2dl dF91bml0KGRldik7DQorCWludAkJcmlkID0gMDsNCisJdm9pZAkJKmloOw0K KwlzdHJ1Y3QgcmVzb3VyY2UJKmlycXJlczsNCiANCi0Jd2x2YWwgPSBwY2lf Y29uZl9yZWFkKGNvbmZpZ19pZCwgUENJX0lEX1JFRyk7DQorCWlmIChhbWRf aW5pdChkZXYpKQ0KKwkJcmV0dXJuIEVOWElPOw0KIA0KLQlpZiAod2x2YWwg PT0gUENJX0RFVklDRV9JRF9BTUQ1M0M5NzQpIHsNCi0JCWlmICgoYW1kID0g YW1kX2luaXQodW5pdCwgY29uZmlnX2lkKSkgPT0gTlVMTCkNCi0JCQlyZXR1 cm47DQotDQotCQkvKiBSZXNldCBQZW5kaW5nIElOVCAqLw0KLQkJaW50c3Rh dCA9IGFtZF9yZWFkOChhbWQsIElOVFNUQVRSRUcpOw0KLQl9DQorCS8qIFJl c2V0IFBlbmRpbmcgSU5UICovDQorCWludHN0YXQgPSBhbWRfcmVhZDgoYW1k LCBJTlRTVEFUUkVHKTsNCiANCiAJLyogQWZ0ZXIgc2V0dGluZyB1cCB0aGUg YWRhcHRlciwgbWFwIG91ciBpbnRlcnJ1cHQgKi8NCi0JaWYgKCFwY2lfbWFw X2ludChjb25maWdfaWQsIGFtZF9pbnRyLCBhbWQsICZjYW1faW1hc2spKSB7 DQorCWlycXJlcyA9IGJ1c19hbGxvY19yZXNvdXJjZShkZXYsIFNZU19SRVNf SVJRLCAmcmlkLCAwLCB+MCwgMSwNCisJCQkJICAgIFJGX1NIQVJFQUJMRSB8 IFJGX0FDVElWRSk7DQorCWlmIChpcnFyZXMgPT0gTlVMTCB8fA0KKwkgICAg YnVzX3NldHVwX2ludHIoZGV2LCBpcnFyZXMsIElOVFJfVFlQRV9DQU0sIGFt ZF9pbnRyLCBhbWQsICZpaCkpIHsNCiAJCWlmIChib290dmVyYm9zZSkNCiAJ CQlwcmludGYoImFtZCVkOiB1bmFibGUgdG8gcmVnaXN0ZXIgaW50ZXJydXB0 IGhhbmRsZXIhXG4iLA0KIAkJCSAgICAgICB1bml0KTsNCi0JCWZyZWUoYW1k LCBNX0RFVkJVRik7DQotCQlyZXR1cm47DQorCQlyZXR1cm4gRU5YSU87DQog CX0NCiANCiAJLyoNCkBAIC0yNDAyLDI0ICsyMzc5LDIwIEBADQogCSAqIG1h eF9zaW1fdHJhbnNhY3Rpb25zDQogCSAqLw0KIAlkZXZxID0gY2FtX3NpbXFf YWxsb2MoTUFYX1NUQVJUX0pPQik7DQotCWlmIChkZXZxID09IE5VTEwpIHsN Ci0JCWZyZWUoYW1kLCBNX0RFVkJVRik7DQotCQlyZXR1cm47DQotCX0NCisJ aWYgKGRldnEgPT0gTlVMTCkNCisJCXJldHVybiBFTlhJTzsNCiANCiAJYW1k LT5wc2ltID0gY2FtX3NpbV9hbGxvYyhhbWRfYWN0aW9uLCBhbWRfcG9sbCwg ImFtZCIsDQogCQkJCSAgYW1kLCBhbWQtPnVuaXQsIDEsIE1BWF9UQUdTX0NN RF9RVUVVRSwNCiAJCQkJICBkZXZxKTsNCiAJaWYgKGFtZC0+cHNpbSA9PSBO VUxMKSB7DQogCQljYW1fc2ltcV9mcmVlKGRldnEpOw0KLQkJZnJlZShhbWQs IE1fREVWQlVGKTsNCi0JCXJldHVybjsNCisJCXJldHVybiBFTlhJTzsNCiAJ fQ0KIA0KIAlpZiAoeHB0X2J1c19yZWdpc3RlcihhbWQtPnBzaW0sIDApICE9 IENBTV9TVUNDRVNTKSB7DQogCQljYW1fc2ltX2ZyZWUoYW1kLT5wc2ltLCAv KmZyZWVfZGV2cSovVFJVRSk7DQotCQlmcmVlKGFtZCwgTV9ERVZCVUYpOw0K LQkJcmV0dXJuOw0KKwkJcmV0dXJuIEVOWElPOw0KIAl9DQogDQogCWlmICh4 cHRfY3JlYXRlX3BhdGgoJmFtZC0+cHBhdGgsIC8qIHBlcmlwaCAqLyBOVUxM LA0KQEAgLTI0MjcsMTcgKzI0MDAsMzMgQEANCiAJCQkgICAgQ0FNX0xVTl9X SUxEQ0FSRCkgIT0gQ0FNX1JFUV9DTVApIHsNCiAJCXhwdF9idXNfZGVyZWdp c3RlcihjYW1fc2ltX3BhdGgoYW1kLT5wc2ltKSk7DQogCQljYW1fc2ltX2Zy ZWUoYW1kLT5wc2ltLCAvKiBmcmVlX3NpbXEgKi8gVFJVRSk7DQotCQlmcmVl KGFtZCwgTV9ERVZCVUYpOw0KLQkJcmV0dXJuOw0KKwkJcmV0dXJuIEVOWElP Ow0KIAl9DQorDQorCXJldHVybiAwOw0KIH0NCiANCi1zdGF0aWMgY29uc3Qg Y2hhciAqDQotYW1kX3Byb2JlKHBjaWNpX3QgdGFnLCBwY2lkaV90IHR5cGUp DQorc3RhdGljIGludA0KK2FtZF9wcm9iZShkZXZpY2VfdCBkZXYpDQogew0K LQlpZiAodHlwZSA9PSBQQ0lfREVWSUNFX0lEX0FNRDUzQzk3NCkgew0KLQkJ cmV0dXJuICgiVGVrcmFtIERDMzkwKFQpL0FNRDUzYzk3NCBTQ1NJIEhvc3Qg QWRhcHRlciIpOw0KLQl9IGVsc2Ugew0KLQkJcmV0dXJuIChOVUxMKTsNCisJ aWYgKHBjaV9nZXRfZGV2aWQoZGV2KSA9PSBQQ0lfREVWSUNFX0lEX0FNRDUz Qzk3NCkgew0KKwkJZGV2aWNlX3NldF9kZXNjKGRldiwNCisJCQkiVGVrcmFt IERDMzkwKFQpL0FNRDUzYzk3NCBTQ1NJIEhvc3QgQWRhcHRlciIpOw0KKwkJ cmV0dXJuIDA7DQogCX0NCisJcmV0dXJuIEVOWElPOw0KIH0NCisNCitzdGF0 aWMgZGV2aWNlX21ldGhvZF90IGFtZF9tZXRob2RzW10gPSB7DQorCS8qIERl dmljZSBpbnRlcmZhY2UgKi8NCisJREVWTUVUSE9EKGRldmljZV9wcm9iZSwJ CWFtZF9wcm9iZSksDQorCURFVk1FVEhPRChkZXZpY2VfYXR0YWNoLAlhbWRf YXR0YWNoKSwNCisJeyAwLCAwIH0NCit9Ow0KKw0KK3N0YXRpYyBkcml2ZXJf dCBhbWRfZHJpdmVyID0gew0KKwkiYW1kIiwgYW1kX21ldGhvZHMsIHNpemVv ZihzdHJ1Y3QgYW1kX3NvZnRjKQ0KK307DQorDQorc3RhdGljIGRldmNsYXNz X3QgYW1kX2RldmNsYXNzOw0KK0RSSVZFUl9NT0RVTEUoYW1kLCBwY2ksIGFt ZF9kcml2ZXIsIGFtZF9kZXZjbGFzcywgMCwgMCk7DQpJbmRleDogc3lzL3Bj aS9hbWQuaA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9o b21lL25jdnMvc3JjL3N5cy9wY2kvYW1kLmgsdg0KcmV0cmlldmluZyByZXZp c2lvbiAxLjENCmRpZmYgLXUgLXIxLjEgYW1kLmgNCi0tLSBzeXMvcGNpL2Ft ZC5oCTE5OTkvMDUvMjIgMjE6NTA6NDAJMS4xDQorKysgc3lzL3BjaS9hbWQu aAkyMDAwLzAzLzMxIDA5OjU2OjQ5DQpAQCAtMTkyLDYgKzE5Miw3IEBADQog ICogUGVyLWFkYXB0ZXIsIHNvZnR3YXJlIGNvbmZpZ3VyYXRpb24uDQogICov DQogc3RydWN0IGFtZF9zb2Z0YyB7DQorCWRldmljZV90CQlkZXY7DQogCWJ1 c19zcGFjZV90YWdfdAkJdGFnOw0KIAlidXNfc3BhY2VfaGFuZGxlX3QJYnNo Ow0KIAlidXNfZG1hX3RhZ190CQlidWZmZXJfZG1hdDsgICAvKiBkbWF0IGZv ciBidWZmZXIgSS9PICovICANCkBAIC0yMDksNyArMjEwLDYgQEANCiAJc3Ry dWN0CSAgIHNyYl9xdWV1ZSB3YWl0aW5nX3NyYnM7DQogCXN0cnVjdAkgICBz cmJfcXVldWUgcnVubmluZ19zcmJzOw0KIA0KLQlwY2ljaV90CSAgIGNvbmZp Z19pZDsNCiAJc3RydWN0CSAgIGFtZF9zcmIgKnBUbXBTUkI7DQogDQogCXVf aW50MTZfdCAgU1JCQ291bnQ7DQo= --673024-1863453750-960878988=:5729 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="advansys.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: advansys newbusify diff Content-Disposition: attachment; filename="advansys.diff" SW5kZXg6IHN5cy9jb25mL2ZpbGVzDQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL2NvbmYvZmlsZXMsdg0K cmV0cmlldmluZyByZXZpc2lvbiAxLjM0Ng0KZGlmZiAtdSAtcjEuMzQ2IGZp bGVzDQotLS0gc3lzL2NvbmYvZmlsZXMJMjAwMC8wMy8zMCAwNToxNjoxNAkx LjM0Ng0KKysrIHN5cy9jb25mL2ZpbGVzCTIwMDAvMDQvMDEgMTM6MTg6MTQN CkBAIC05Niw3ICs5Niw2IEBADQogZGRiL2RiX3dhdGNoLmMJCW9wdGlvbmFs IGRkYg0KIGRkYi9kYl93cml0ZV9jbWQuYwlvcHRpb25hbCBkZGINCiBkZXYv YWR2YW5zeXMvYWR2X2Vpc2EuYwlvcHRpb25hbCBhZHYgZWlzYQ0KLWRldi9h ZHZhbnN5cy9hZHZfaXNhLmMJb3B0aW9uYWwgYWR2IGlzYQ0KIGRldi9hZHZh bnN5cy9hZHZfcGNpLmMJb3B0aW9uYWwgYWR2IHBjaQ0KIGRldi9hZHZhbnN5 cy9hZHZhbnN5cy5jCW9wdGlvbmFsIGFkdg0KIGRldi9hZHZhbnN5cy9hZHZs aWIuYwlvcHRpb25hbCBhZHYNCkluZGV4OiBzeXMvY29uZi9maWxlcy5hbHBo YQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL25j dnMvc3JjL3N5cy9jb25mL2ZpbGVzLmFscGhhLHYNCnJldHJpZXZpbmcgcmV2 aXNpb24gMS40NQ0KZGlmZiAtdSAtcjEuNDUgZmlsZXMuYWxwaGENCi0tLSBz eXMvY29uZi9maWxlcy5hbHBoYQkyMDAwLzAzLzI5IDE0OjMyOjMwCTEuNDUN CisrKyBzeXMvY29uZi9maWxlcy5hbHBoYQkyMDAwLzA0LzAxIDEzOjE4OjU4 DQpAQCAtMTU5LDYgKzE1OSw3IEBADQogYWxwaGEvcGNpL3BjaWJ1cy5jCQlv cHRpb25hbAlwY2kNCiBhbHBoYS9wY2kvdHN1bmFtaS5jCQlvcHRpb25hbAlk ZWNfc3Q2NjAwDQogYWxwaGEvcGNpL3RzdW5hbWlfcGNpLmMJCW9wdGlvbmFs CWRlY19zdDY2MDANCitkZXYvYWR2YW5zeXMvYWR2X2lzYS5jCQlvcHRpb25h bAlhZHYgaXNhDQogZGV2L2FpYy9haWNfaXNhLmMJCW9wdGlvbmFsCWFpYyBp c2ENCiBkZXYvYXRhL2F0YS1hbGwuYwkJb3B0aW9uYWwJYXRhDQogZGV2L2F0 YS9hdGEtZGlzay5jCQlvcHRpb25hbAlhdGFkaXNrDQpJbmRleDogc3lzL2Nv bmYvZmlsZXMuaTM4Ng0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZp bGU6IC9ob21lL25jdnMvc3JjL3N5cy9jb25mL2ZpbGVzLmkzODYsdg0KcmV0 cmlldmluZyByZXZpc2lvbiAxLjMxNQ0KZGlmZiAtdSAtcjEuMzE1IGZpbGVz LmkzODYNCi0tLSBzeXMvY29uZi9maWxlcy5pMzg2CTIwMDAvMDMvMzAgMDU6 MTY6MTUJMS4zMTUNCisrKyBzeXMvY29uZi9maWxlcy5pMzg2CTIwMDAvMDQv MDEgMTM6MTg6NDINCkBAIC02MCw2ICs2MCw3IEBADQogY29udHJpYi9kZXYv b2x0ci90cmxsZGJtLmMJb3B0aW9uYWwJb2x0cg0KIGNvbnRyaWIvZGV2L29s dHIvdHJsbGRobS5jCW9wdGlvbmFsCW9sdHINCiBjb250cmliL2Rldi9vbHRy L3RybGxkbWFjLmMJb3B0aW9uYWwJb2x0cg0KK2Rldi9hZHZhbnN5cy9hZHZf aXNhLmMJCW9wdGlvbmFsCWFkdiBpc2ENCiBkZXYvYWljL2FpY19pc2EuYwkJ b3B0aW9uYWwJYWljIGlzYQ0KIGRldi9hdGEvYXRhLWFsbC5jCQlvcHRpb25h bAlhdGEgDQogZGV2L2F0YS9hdGEtZGlzay5jCQlvcHRpb25hbAlhdGFkaXNr DQpJbmRleDogc3lzL2NvbmYvZmlsZXMucGM5OA0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5cy9jb25mL2Zp bGVzLnBjOTgsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjE0Nw0KZGlmZiAt dSAtcjEuMTQ3IGZpbGVzLnBjOTgNCi0tLSBzeXMvY29uZi9maWxlcy5wYzk4 CTIwMDAvMDMvMzAgMDU6MTY6MTYJMS4xNDcNCisrKyBzeXMvY29uZi9maWxl cy5wYzk4CTIwMDAvMDQvMDEgMTM6MTk6MTcNCkBAIC01Nyw2ICs1Nyw3IEBA DQogY29udHJpYi9kZXYvb2x0ci90cmxsZGJtLmMJb3B0aW9uYWwJb2x0cg0K IGNvbnRyaWIvZGV2L29sdHIvdHJsbGRobS5jCW9wdGlvbmFsCW9sdHINCiBj b250cmliL2Rldi9vbHRyL3RybGxkbWFjLmMJb3B0aW9uYWwJb2x0cg0KKyNk ZXYvYWR2YW5zeXMvYWR2X2lzYS5jCQlvcHRpb25hbAlhZHYgaXNhDQogZGV2 L2FpYy9haWNfY2J1cy5jCQlvcHRpb25hbAlhaWMgaXNhDQogZGV2L2F0YS9h dGEtYWxsLmMJCW9wdGlvbmFsCWF0YSANCiBkZXYvYXRhL2F0YS1kbWEuYwkJ b3B0aW9uYWwJYXRhIA0KSW5kZXg6IHN5cy9kZXYvYWR2YW5zeXMvYWR2X2Vp c2EuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9ob21l L25jdnMvc3JjL3N5cy9kZXYvYWR2YW5zeXMvYWR2X2Vpc2EuYyx2DQpyZXRy aWV2aW5nIHJldmlzaW9uIDEuOQ0KZGlmZiAtdSAtcjEuOSBhZHZfZWlzYS5j DQotLS0gc3lzL2Rldi9hZHZhbnN5cy9hZHZfZWlzYS5jCTIwMDAvMDEvMjkg MTg6MjE6MjEJMS45DQorKysgc3lzL2Rldi9hZHZhbnN5cy9hZHZfZWlzYS5j CTIwMDAvMDMvMzEgMTA6MTc6NTQNCkBAIC03OCwxMCArNzgsOCBAQA0KIHN0 YXRpYwlidXNfZG1hbWFwX3QJb3ZlcnJ1bl9kbWFtYXA7DQogc3RhdGljCWJ1 c19hZGRyX3QJb3ZlcnJ1bl9waHlzYmFzZTsNCiANCi1zdGF0aWMgY29uc3Qg Y2hhciAqYWR2ZWlzYW1hdGNoKGVpc2FfaWRfdCB0eXBlKTsNCi0NCiBzdGF0 aWMgY29uc3QgY2hhcioNCi1hZHZlaXNhbWF0Y2goZWlzYV9pZF90IHR5cGUp DQorYWR2X2Vpc2FfbWF0Y2goZWlzYV9pZF90IHR5cGUpDQogew0KIAlzd2l0 Y2ggKHR5cGUgJiB+MHhGKSB7DQogCWNhc2UgRUlTQV9ERVZJQ0VfSURfQURW QU5TWVNfNzQwOg0KQEAgLTk3LDE5ICs5NSwxOCBAQA0KIH0NCiANCiBzdGF0 aWMgaW50DQotYWR2ZWlzYXByb2JlKGRldmljZV90IGRldikNCithZHZfZWlz YV9wcm9iZShkZXZpY2VfdCBkZXYpDQogew0KIAljb25zdCBjaGFyICpkZXNj Ow0KIAl1X2ludDMyX3QgaW9iYXNlOw0KIAl1X2ludDhfdCBpcnE7DQogDQot CWRlc2MgPSBhZHZlaXNhbWF0Y2goZWlzYV9nZXRfaWQoZGV2KSk7DQorCWRl c2MgPSBhZHZfZWlzYV9tYXRjaChlaXNhX2dldF9pZChkZXYpKTsNCiAJaWYg KCFkZXNjKQ0KIAkJcmV0dXJuIChFTlhJTyk7DQogCWRldmljZV9zZXRfZGVz YyhkZXYsIGRlc2MpOw0KIA0KLQlpb2Jhc2UgPSAoZWlzYV9nZXRfc2xvdChk ZXYpICogRUlTQV9TTE9UX1NJWkUpDQotCSAgICArIEFEVl9FSVNBX1NMT1Rf T0ZGU0VUOw0KKwlpb2Jhc2UgPSAoZWlzYV9nZXRfc2xvdChkZXYpICogRUlT QV9TTE9UX1NJWkUpICsgQURWX0VJU0FfU0xPVF9PRkZTRVQ7DQogDQogCWVp c2FfYWRkX2lvc3BhY2UoZGV2LCBpb2Jhc2UsIEFEVl9FSVNBX0lPU0laRSwg UkVTVkFERFJfTk9ORSk7DQogCWlycSA9IGluYihpb2Jhc2UgKyBBRFZfRUlT QV9JUlFfQlVSU1RfTEVOX1JFRyk7DQpAQCAtMTMzLDEzICsxMzAsMTIgQEAN CiB9DQogDQogc3RhdGljIGludA0KLWFkdmVpc2FhdHRhY2goZGV2aWNlX3Qg ZGV2KQ0KK2Fkdl9laXNhX2F0dGFjaChkZXZpY2VfdCBkZXYpDQogew0KIAlz dHJ1Y3QgYWR2X3NvZnRjICphZHY7DQogCXN0cnVjdCBhZHZfc29mdGMgKmFk dl9iOw0KIAlzdHJ1Y3QgcmVzb3VyY2UgKmlvOw0KIAlzdHJ1Y3QgcmVzb3Vy Y2UgKmlycTsNCi0JaW50IHVuaXQgPSBkZXZpY2VfZ2V0X3VuaXQoZGV2KTsN CiAJaW50IHJpZCwgZXJyb3I7DQogCXZvaWQgKmloOw0KIA0KQEAgLTE2NSw3 ICsxNjEsNyBAQA0KIA0KIAlzd2l0Y2ggKGVpc2FfZ2V0X2lkKGRldikgJiB+ MHhGKSB7DQogCWNhc2UgRUlTQV9ERVZJQ0VfSURfQURWQU5TWVNfNzUwOg0K LQkJYWR2X2IgPSBhZHZfYWxsb2ModW5pdCwgcm1hbl9nZXRfYnVzdGFnKGlv KSwNCisJCWFkdl9iID0gYWR2X2FsbG9jKGRldiwgcm1hbl9nZXRfYnVzdGFn KGlvKSwNCiAJCQkJICBybWFuX2dldF9idXNoYW5kbGUoaW8pICsgQURWX0VJ U0FfT0ZGU0VUX0NIQU4yKTsNCiAJCWlmIChhZHZfYiA9PSBOVUxMKQ0KIAkJ CWdvdG8gYmFkOw0KQEAgLTE5Nyw3ICsxOTMsNyBAQA0KIA0KIAkJLyogRkFM TFRIUk9VR0ggKi8NCiAJY2FzZSBFSVNBX0RFVklDRV9JRF9BRFZBTlNZU183 NDA6DQotCQlhZHYgPSBhZHZfYWxsb2ModW5pdCwgcm1hbl9nZXRfYnVzdGFn KGlvKSwNCisJCWFkdiA9IGFkdl9hbGxvYyhkZXYsIHJtYW5fZ2V0X2J1c3Rh ZyhpbyksDQogCQkJCXJtYW5fZ2V0X2J1c2hhbmRsZShpbykgKyBBRFZfRUlT QV9PRkZTRVRfQ0hBTjEpOw0KIAkJaWYgKGFkdiA9PSBOVUxMKSB7DQogCQkJ aWYgKGFkdl9iICE9IE5VTEwpDQpAQCAtMzMwLDE4ICszMjYsMTQgQEANCiAN CiBzdGF0aWMgZGV2aWNlX21ldGhvZF90IGFkdl9laXNhX21ldGhvZHNbXSA9 IHsNCiAJLyogRGV2aWNlIGludGVyZmFjZSAqLw0KLQlERVZNRVRIT0QoZGV2 aWNlX3Byb2JlLAkJYWR2ZWlzYXByb2JlKSwNCi0JREVWTUVUSE9EKGRldmlj ZV9hdHRhY2gsCWFkdmVpc2FhdHRhY2gpLA0KLQ0KKwlERVZNRVRIT0QoZGV2 aWNlX3Byb2JlLAkJYWR2X2Vpc2FfcHJvYmUpLA0KKwlERVZNRVRIT0QoZGV2 aWNlX2F0dGFjaCwJYWR2X2Vpc2FfYXR0YWNoKSwNCiAJeyAwLCAwIH0NCiB9 Ow0KIA0KIHN0YXRpYyBkcml2ZXJfdCBhZHZfZWlzYV9kcml2ZXIgPSB7DQot CSJhZHYiLA0KLQlhZHZfZWlzYV9tZXRob2RzLA0KLQkxLAkJCS8qIHVudXNl ZCAqLw0KKwkiYWR2IiwgYWR2X2Vpc2FfbWV0aG9kcywgc2l6ZW9mKHN0cnVj dCBhZHZfc29mdGMpDQogfTsNCi0NCi1zdGF0aWMgZGV2Y2xhc3NfdCBhZHZf ZGV2Y2xhc3M7DQogDQotRFJJVkVSX01PRFVMRShhZHYsIGVpc2EsIGFkdl9l aXNhX2RyaXZlciwgYWR2X2RldmNsYXNzLCAwLCAwKTsNCitzdGF0aWMgZGV2 Y2xhc3NfdCBhZHZfZWlzYV9kZXZjbGFzczsNCitEUklWRVJfTU9EVUxFKGFk diwgZWlzYSwgYWR2X2Vpc2FfZHJpdmVyLCBhZHZfZWlzYV9kZXZjbGFzcywg MCwgMCk7DQpJbmRleDogc3lzL2Rldi9hZHZhbnN5cy9hZHZfaXNhLmMNCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3Ny Yy9zeXMvZGV2L2FkdmFuc3lzL2Fkdl9pc2EuYyx2DQpyZXRyaWV2aW5nIHJl dmlzaW9uIDEuMTQNCmRpZmYgLXUgLXIxLjE0IGFkdl9pc2EuYw0KLS0tIHN5 cy9kZXYvYWR2YW5zeXMvYWR2X2lzYS5jCTIwMDAvMDEvMTcgMTI6NDk6NTQJ MS4xNA0KKysrIHN5cy9kZXYvYWR2YW5zeXMvYWR2X2lzYS5jCTIwMDAvMDQv MDEgMTM6MTk6MzkNCkBAIC00OSwxMSArNDksMTUgQEANCiANCiAjaW5jbHVk ZSA8c3lzL3BhcmFtLmg+DQogI2luY2x1ZGUgPHN5cy9zeXN0bS5oPiANCisj aW5jbHVkZSA8c3lzL2tlcm5lbC5oPiANCiANCiAjaW5jbHVkZSA8bWFjaGlu ZS9idXNfcGlvLmg+DQogI2luY2x1ZGUgPG1hY2hpbmUvYnVzLmg+DQorI2lu Y2x1ZGUgPG1hY2hpbmUvcmVzb3VyY2UuaD4NCisjaW5jbHVkZSA8c3lzL2J1 cy5oPiANCisjaW5jbHVkZSA8c3lzL3JtYW4uaD4gDQogDQotI2luY2x1ZGUg PGkzODYvaXNhL2lzYV9kZXZpY2UuaD4NCisjaW5jbHVkZSA8aXNhL2lzYXZh ci5oPg0KIA0KICNpbmNsdWRlIDxkZXYvYWR2YW5zeXMvYWR2YW5zeXMuaD4N CiANCkBAIC05MSwyNiArOTUsMjEgQEANCiANCiAjZGVmaW5lIE1BWF9JU0Ff SU9QT1JUX0lOREVYIChzaXplb2YoYWR2X2lzYV9pb3BvcnRzKS9zaXplb2Yo dV9pbnQxNl90KSAtIDEpDQogDQotc3RhdGljCWludAlhZHZpc2Fwcm9iZShz dHJ1Y3QgaXNhX2RldmljZSAqaWQpOw0KLXN0YXRpYyAgaW50CWFkdmlzYWF0 dGFjaChzdHJ1Y3QgaXNhX2RldmljZSAqaWQpOw0KK3N0YXRpYwlpbnQJYWR2 X2lzYV9wcm9iZShkZXZpY2VfdCBkZXYpOw0KK3N0YXRpYyAgaW50CWFkdl9p c2FfYXR0YWNoKGRldmljZV90IGRldik7DQogc3RhdGljCXZvaWQJYWR2X3Nl dF9pc2FwbnBfd2FpdF9mb3Jfa2V5KHZvaWQpOw0KIHN0YXRpYwlpbnQJYWR2 X2dldF9pc2FfZG1hX2NoYW5uZWwoc3RydWN0IGFkdl9zb2Z0YyAqYWR2KTsN CiBzdGF0aWMJaW50CWFkdl9zZXRfaXNhX2RtYV9zZXR0aW5ncyhzdHJ1Y3Qg YWR2X3NvZnRjICphZHYpOw0KIA0KLXN0YXRpYyB2b2lkCWFkdl9pc2FfaW50 cih2b2lkICp1bml0KTsNCi0NCi1zdHJ1Y3QgaXNhX2RyaXZlciBhZHZkcml2 ZXIgPQ0KLXsNCi0JYWR2aXNhcHJvYmUsDQotCWFkdmlzYWF0dGFjaCwNCi0J ImFkdiINCi19Ow0KLQ0KIHN0YXRpYyBpbnQNCi1hZHZpc2Fwcm9iZShzdHJ1 Y3QgaXNhX2RldmljZSAqaWQpDQorYWR2X2lzYV9wcm9iZShkZXZpY2VfdCBk ZXYpDQogew0KIAlpbnQJcG9ydF9pbmRleDsNCiAJaW50CW1heF9wb3J0X2lu ZGV4Ow0KKwl1X2xvbmcJaW9iYXNlLCBpcnE7DQorCWludAlyaWQgPSAwOw0K Kwl2b2lkCSppaDsNCisJc3RydWN0IHJlc291cmNlCSppb3JlcywgKmlycXJl czsNCiANCiAJLyoNCiAJICogRGVmYXVsdCB0byBzY2FubmluZyBhbGwgcG9z c2libGUgZGV2aWNlIGxvY2F0aW9ucy4NCkBAIC0xMTgsMTkgKzExNywxOSBA QA0KIAlwb3J0X2luZGV4ID0gMDsNCiAJbWF4X3BvcnRfaW5kZXggPSBNQVhf SVNBX0lPUE9SVF9JTkRFWDsNCiANCi0JaWYgKGlkLT5pZF9pb2Jhc2UgPiAw KSB7DQorCWlmIChidXNfZ2V0X3Jlc291cmNlKGRldiwgU1lTX1JFU19JT1BP UlQsIDAsICZpb2Jhc2UsIE5VTEwpID09IDApIHsNCiAJCWZvciAoO3BvcnRf aW5kZXggPD0gbWF4X3BvcnRfaW5kZXg7IHBvcnRfaW5kZXgrKykNCi0JCQlp ZiAoaWQtPmlkX2lvYmFzZSA8PSBhZHZfaXNhX2lvcG9ydHNbcG9ydF9pbmRl eF0pDQorCQkJaWYgKGlvYmFzZSA8PSBhZHZfaXNhX2lvcG9ydHNbcG9ydF9p bmRleF0pDQogCQkJCWJyZWFrOw0KIAkJaWYgKChwb3J0X2luZGV4ID4gbWF4 X3BvcnRfaW5kZXgpDQotCQkgfHwgKGlkLT5pZF9pb2Jhc2UgIT0gYWR2X2lz YV9pb3BvcnRzW3BvcnRfaW5kZXhdKSkgew0KLQkJCXByaW50ZigiYWR2JWQ6 IEludmFsaWQgYmFzZXBvcnQgb2YgMHgleCBzcGVjaWZpZWQuICINCisJCSB8 fCAoaW9iYXNlICE9IGFkdl9pc2FfaW9wb3J0c1twb3J0X2luZGV4XSkpIHsN CisJCQlwcmludGYoImFkdiVkOiBJbnZhbGlkIGJhc2Vwb3J0IG9mIDB4JWx4 IHNwZWNpZmllZC4gIg0KIAkJCQkiTmVlcmVzdCB2YWxpZCBiYXNlcG9ydCBp cyAweCV4LiAgRmFpbGluZyAiDQotCQkJCSJwcm9iZS5cbiIsIGlkLT5pZF91 bml0LCBpZC0+aWRfaW9iYXNlLA0KKwkJCQkicHJvYmUuXG4iLCBkZXZpY2Vf Z2V0X3VuaXQoZGV2KSwgaW9iYXNlLA0KIAkJCQkocG9ydF9pbmRleCA8PSBt YXhfcG9ydF9pbmRleCkgPw0KIAkJCQkJYWR2X2lzYV9pb3BvcnRzW3BvcnRf aW5kZXhdIDoNCiAJCQkJCWFkdl9pc2FfaW9wb3J0c1ttYXhfcG9ydF9pbmRl eF0pOw0KLQkJCXJldHVybiAwOw0KKwkJCXJldHVybiBFTlhJTzsNCiAJCX0N CiAJCW1heF9wb3J0X2luZGV4ID0gcG9ydF9pbmRleDsNCiAJfQ0KQEAgLTE0 NiwyNSArMTQ1LDI4IEBADQogDQogCQlpZiAocG9ydF9hZGRyID09IDApDQog CQkJLyogQWxyZWFkeSBiZWVuIGF0dGFjaGVkICovDQorCQkJY29udGludWU7 DQorCQkNCisJCWlmIChidXNfc2V0X3Jlc291cmNlKGRldiwgU1lTX1JFU19J T1BPUlQsIDAsIHBvcnRfYWRkciwgMSkpDQogCQkJY29udGludWU7DQotCQlp ZC0+aWRfaW9iYXNlID0gcG9ydF9hZGRyOw0KLQkJaWYgKGhhdmVzZWVuX2lv YmFzZShpZCwgMSkpCS8qIFhYWCByZWFsIHBvcnRzaXplPyAqLw0KKw0KKwkJ LyogWFhYIHdoYXQgaXMgdGhlIHJlYWwgcG9ydHNpemU/ICovDQorCQlpb3Jl cyA9IGJ1c19hbGxvY19yZXNvdXJjZShkZXYsIFNZU19SRVNfSU9QT1JULCAm cmlkLCAwLCB+MCwgMSwNCisJCQkJCSAgIFJGX0FDVElWRSk7DQorCQlpZiAo aW9yZXMgPT0gTlVMTCkNCiAJCQljb250aW51ZTsNCiANCi0JCWlmIChhZHZf ZmluZF9zaWduYXR1cmUoSTM4Nl9CVVNfU1BBQ0VfSU8sIHBvcnRfYWRkcikp IHsNCisJCWlmIChhZHZfZmluZF9zaWduYXR1cmUocm1hbl9nZXRfYnVzdGFn KGlvcmVzKSwNCisJCQkJICAgICAgIHJtYW5fZ2V0X2J1c2hhbmRsZShpb3Jl cykpKSB7DQogCQkJLyoNCiAJCQkgKiBHb3Qgb25lLiAgTm93IGFsbG9jYXRl IG91ciBzb2Z0Yw0KIAkJCSAqIGFuZCBzZWUgaWYgd2UgY2FuIGluaXRpYWxp emUgdGhlIGNhcmQuDQogCQkJICovDQogCQkJc3RydWN0IGFkdl9zb2Z0YyAq YWR2Ow0KLQkJCWFkdiA9IGFkdl9hbGxvYyhpZC0+aWRfdW5pdCwgSTM4Nl9C VVNfU1BBQ0VfSU8sDQotCQkJCQlwb3J0X2FkZHIpOw0KKwkJCWFkdiA9IGFk dl9hbGxvYyhkZXYsIHJtYW5fZ2V0X2J1c3RhZyhpb3JlcyksDQorCQkJCQly bWFuX2dldF9idXNoYW5kbGUoaW9yZXMpKTsNCiAJCQlpZiAoYWR2ID09IE5V TEwpDQotCQkJCXJldHVybiAoMCk7DQotDQotCQkJYWR2X3VuaXQrKzsNCi0N Ci0JCQlpZC0+aWRfaW9iYXNlID0gYWR2LT5ic2g7DQorCQkJCXJldHVybiBF TlhJTzsNCiANCiAJCQkvKg0KIAkJCSAqIFN0b3AgdGhlIGNoaXAuDQpAQCAt MTgyLDcgKzE4NCw3IEBADQogCQkJCW1heHNlZ3N6ID0gQURWX1ZMX01BWF9E TUFfQ09VTlQ7DQogCQkJCW1heHNpemUgPSBCVVNfU1BBQ0VfTUFYU0laRV8z MkJJVDsNCiAJCQkJbG93YWRkciA9IEFEVl9WTF9NQVhfRE1BX0FERFI7DQot CQkJCWlkLT5pZF9kcnEgPSAtMTsJCQkJDQorCQkJCWJ1c19kZWxldGVfcmVz b3VyY2UoZGV2LCBTWVNfUkVTX0RSUSwgMCk7DQogCQkJfSBlbHNlIGlmICgo YWR2LT5jaGlwX3ZlcnNpb24gPj0gQURWX0NISVBfTUlOX1ZFUl9JU0EpDQog CQkJCSYmIChhZHYtPmNoaXBfdmVyc2lvbiA8PSBBRFZfQ0hJUF9NQVhfVkVS X0lTQSkpIHsNCiAJCQkJaWYgKGFkdi0+Y2hpcF92ZXJzaW9uID49IEFEVl9D SElQX01JTl9WRVJfSVNBX1BOUCkgew0KQEAgLTE5OCw3ICsyMDAsOCBAQA0K IAkJCQlhZHYtPmlzYV9kbWFfc3BlZWQgPSBBRFZfREVGX0lTQV9ETUFfU1BF RUQ7DQogCQkJCWFkdi0+aXNhX2RtYV9jaGFubmVsID0NCiAJCQkJICAgIGFk dl9nZXRfaXNhX2RtYV9jaGFubmVsKGFkdik7DQotCQkJCWlkLT5pZF9kcnEg PSBhZHYtPmlzYV9kbWFfY2hhbm5lbDsNCisJCQkJYnVzX3NldF9yZXNvdXJj ZShkZXYsIFNZU19SRVNfRFJRLCAwLA0KKwkJCQkJCSBhZHYtPmlzYV9kbWFf Y2hhbm5lbCwgMSk7DQogCQkJfSBlbHNlIHsNCiAJCQkJcGFuaWMoImFkdmlz YXByb2JlOiBVbmtub3duIGNhcmQgcmV2aXNpb25cbiIpOw0KIAkJCX0NCkBA IC0yMjYsNyArMjI5LDcgQEANCiAJCQkJcHJpbnRmKCIlczogQ291bGQgbm90 IGFsbG9jYXRlIERNQSB0YWcgLSBlcnJvciAlZFxuIiwNCiAJCQkJICAgICAg IGFkdl9uYW1lKGFkdiksIGVycm9yKTsgDQogCQkJCWFkdl9mcmVlKGFkdik7 IA0KLQkJCQlyZXR1cm4gKDApOyANCisJCQkJcmV0dXJuIEVOWElPOyANCiAJ CQl9DQogDQogCQkJYWR2LT5pbml0X2xldmVsKys7DQpAQCAtMjQ2LDcgKzI0 OSw3IEBADQogCQkJCQkJICAgICAgIC8qZmxhZ3MqLzAsDQogCQkJCQkJICAg ICAgICZvdmVycnVuX2RtYXQpICE9IDApIHsNCiAJCQkJCWFkdl9mcmVlKGFk dik7DQotCQkJCQlyZXR1cm4gKDApOw0KKwkJCQkJcmV0dXJuIEVOWElPOw0K ICAgICAgICAgCQkJfQ0KIAkJCQlpZiAoYnVzX2RtYW1lbV9hbGxvYyhvdmVy cnVuX2RtYXQsDQogCQkJCQkJICAgICAodm9pZCAqKikmb3ZlcnJ1bl9idWYs DQpAQCAtMjU0LDcgKzI1Nyw3IEBADQogCQkJCQkJICAgICAmb3ZlcnJ1bl9k bWFtYXApICE9IDApIHsNCiAJCQkJCWJ1c19kbWFfdGFnX2Rlc3Ryb3kob3Zl cnJ1bl9kbWF0KTsNCiAJCQkJCWFkdl9mcmVlKGFkdik7DQotCQkJCQlyZXR1 cm4gKDApOw0KKwkJCQkJcmV0dXJuIEVOWElPOw0KIAkJCQl9DQogCQkJCS8q IEFuZCBwZXJtYW5lbnRseSBtYXAgaXQgaW4gKi8gIA0KIAkJCQlidXNfZG1h bWFwX2xvYWQob3ZlcnJ1bl9kbWF0LCBvdmVycnVuX2RtYW1hcCwNCkBAIC0y NjcsNyArMjcwLDcgQEANCiAJCQkNCiAJCQlpZiAoYWR2X2luaXQoYWR2KSAh PSAwKSB7DQogCQkJCWFkdl9mcmVlKGFkdik7DQotCQkJCXJldHVybiAoMCk7 DQorCQkJCXJldHVybiBFTlhJTzsNCiAJCQl9DQogDQogCQkJc3dpdGNoIChh ZHYtPnR5cGUpIHsNCkBAIC0yOTMsMjggKzI5NiwzNSBAQA0KIAkJCX0NCiAJ CQkNCiAJCQkvKiBEZXRlcm1pbmUgb3VyIElSUSAqLw0KLQkJCWlmIChpZC0+ aWRfaXJxID09IDAgLyogaXJxID8gKi8pDQotCQkJCWlkLT5pZF9pcnEgPSAx IDw8IGFkdl9nZXRfY2hpcF9pcnEoYWR2KTsNCisJCQlpZiAoYnVzX2dldF9y ZXNvdXJjZShkZXYsIFNZU19SRVNfSVJRLCAwLCAmaXJxLCBOVUxMKSkNCisJ CQkJYnVzX3NldF9yZXNvdXJjZShkZXYsIFNZU19SRVNfSVJRLCAwLA0KKwkJ CQkJCSBhZHZfZ2V0X2NoaXBfaXJxKGFkdiksIDEpOw0KIAkJCWVsc2UNCi0J CQkJYWR2X3NldF9jaGlwX2lycShhZHYsIGZmcyhpZC0+aWRfaXJxKSAtIDEp Ow0KKwkJCQlhZHZfc2V0X2NoaXBfaXJxKGFkdiwgaXJxKTsNCiANCi0JCQlp ZC0+aWRfaW50ciA9IGFkdl9pc2FfaW50cjsNCi0JCQkNCisJCQlpcnFyZXMg PSBidXNfYWxsb2NfcmVzb3VyY2UoZGV2LCBTWVNfUkVTX0lSUSwgJnJpZCwN CisJCQkJCQkgICAgMCwgfjAsIDEsIFJGX0FDVElWRSk7DQorCQkJaWYgKGly cXJlcyA9PSBOVUxMIHx8DQorCQkJICAgIGJ1c19zZXR1cF9pbnRyKGRldiwg aXJxcmVzLCBJTlRSX1RZUEVfQ0FNLA0KKwkJCQkJICAgYWR2X2ludHIsIGFk diwgJmloKSkgew0KKwkJCQlhZHZfZnJlZShhZHYpOw0KKwkJCQlyZXR1cm4g RU5YSU87DQorCQkJfQ0KKw0KIAkJCS8qIE1hcmsgYXMgcHJvYmVkICovDQog CQkJYWR2X2lzYV9pb3BvcnRzW3BvcnRfaW5kZXhdID0gMDsNCi0JCQlyZXR1 cm4gMTsJLyogWFhYIHdoYXQgaXMgdGhlIHJlYWwgcG9ydHNpemU/ICovDQor CQkJcmV0dXJuIDA7DQogCQl9DQogCX0NCiANCi0JcmV0dXJuIDA7DQorCXJl dHVybiBFTlhJTzsNCiB9DQogDQogc3RhdGljIGludA0KLWFkdmlzYWF0dGFj aChzdHJ1Y3QgaXNhX2RldmljZSAqaWQpDQorYWR2X2lzYV9hdHRhY2goZGV2 aWNlX3QgZGV2KQ0KIHsNCi0Jc3RydWN0IGFkdl9zb2Z0YyAqYWR2Ow0KKwlz dHJ1Y3QgYWR2X3NvZnRjICphZHYgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7 DQogDQotCWFkdiA9IGFkdnNvZnRjc1tpZC0+aWRfdW5pdF07DQogCXJldHVy biAoYWR2X2F0dGFjaChhZHYpKTsNCiB9DQogDQpAQCAtMzY1LDE3ICszNzUs MTggQEANCiAJCW91dGIoQURWX0lTQV9QTlBfUE9SVF9XUklURSwgMHgwMik7 DQogCQlpc2FwbnBfd2FpdF9zZXQrKzsNCiAJfQ0KLQlyZXR1cm47ICAgICAg ICAgICAgICAgICANCiB9DQogDQotLyoNCi0gKiBIYW5kbGUgYW4gSVNBIGlu dGVycnVwdC4NCi0gKiBYWFggc2hvdWxkIGdvIGF3YXkgYXMgc29vbiBhcyBJ U0EgaW50ZXJydXB0IGhhbmRsZXJzDQotICogdGFrZSBhICh2b2lkICopIGFy Zy4NCi0gKi8NCi1zdGF0aWMgdm9pZA0KLWFkdl9pc2FfaW50cih2b2lkICp1 bml0KQ0KLXsNCi0Jc3RydWN0IGFkdl9zb2Z0YyAqYXJnID0gYWR2c29mdGNz WyhpbnQpdW5pdF07DQotCWFkdl9pbnRyKCh2b2lkICopYXJnKTsNCi19DQor c3RhdGljIGRldmljZV9tZXRob2RfdCBhZHZfaXNhX21ldGhvZHNbXSA9IHsN CisJLyogRGV2aWNlIGludGVyZmFjZSAqLw0KKwlERVZNRVRIT0QoZGV2aWNl X3Byb2JlLAkJYWR2X2lzYV9wcm9iZSksDQorCURFVk1FVEhPRChkZXZpY2Vf YXR0YWNoLAlhZHZfaXNhX2F0dGFjaCksDQorCXsgMCwgMCB9DQorfTsNCisN CitzdGF0aWMgZHJpdmVyX3QgYWR2X2lzYV9kcml2ZXIgPSB7DQorCSJhZHYi LCBhZHZfaXNhX21ldGhvZHMsIHNpemVvZihzdHJ1Y3QgYWR2X3NvZnRjKQ0K K307DQorDQorc3RhdGljIGRldmNsYXNzX3QgYWR2X2lzYV9kZXZjbGFzczsN CitEUklWRVJfTU9EVUxFKGFkdiwgaXNhLCBhZHZfaXNhX2RyaXZlciwgYWR2 X2lzYV9kZXZjbGFzcywgMCwgMCk7DQpJbmRleDogc3lzL2Rldi9hZHZhbnN5 cy9hZHZfcGNpLmMNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxl OiAvaG9tZS9uY3ZzL3NyYy9zeXMvZGV2L2FkdmFuc3lzL2Fkdl9wY2kuYyx2 DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMTENCmRpZmYgLXUgLXIxLjExIGFk dl9wY2kuYw0KLS0tIHN5cy9kZXYvYWR2YW5zeXMvYWR2X3BjaS5jCTIwMDAv MDMvMDIgMDA6MDg6MzQJMS4xMQ0KKysrIHN5cy9kZXYvYWR2YW5zeXMvYWR2 X3BjaS5jCTIwMDAvMDMvMzEgMTA6MTE6MDgNCkBAIC02Niw2ICs2Niw5IEBA DQogDQogI2luY2x1ZGUgPG1hY2hpbmUvYnVzX3Bpby5oPg0KICNpbmNsdWRl IDxtYWNoaW5lL2J1cy5oPg0KKyNpbmNsdWRlIDxtYWNoaW5lL3Jlc291cmNl Lmg+DQorI2luY2x1ZGUgPHN5cy9idXMuaD4NCisjaW5jbHVkZSA8c3lzL3Jt YW4uaD4NCiANCiAjaW5jbHVkZSA8cGNpL3BjaXJlZy5oPg0KICNpbmNsdWRl IDxwY2kvcGNpdmFyLmg+DQpAQCAtODQsOCArODcsOCBAQA0KICNkZWZpbmUg QURWX1BDSV9NQVhfRE1BX0FERFIgICAgKDB4RkZGRkZGRkZMKQ0KICNkZWZp bmUgQURWX1BDSV9NQVhfRE1BX0NPVU5UICAgKDB4RkZGRkZGRkZMKQ0KIA0K LXN0YXRpYyBjb25zdCBjaGFyKiBhZHZwY2lwcm9iZShwY2ljaV90IHRhZywg cGNpZGlfdCB0eXBlKTsNCi1zdGF0aWMgdm9pZCBhZHZwY2lhdHRhY2gocGNp Y2lfdCBjb25maWdfaWQsIGludCB1bml0KTsNCitzdGF0aWMgaW50IGFkdl9w Y2lfcHJvYmUoZGV2aWNlX3QpOw0KK3N0YXRpYyBpbnQgYWR2X3BjaV9hdHRh Y2goZGV2aWNlX3QpOw0KIA0KIC8qIA0KICAqIFRoZSBvdmVycnVuIGJ1ZmZl ciBzaGFyZWQgYW1vbmdzdCBhbGwgUENJIGFkYXB0ZXJzLg0KQEAgLTk1LDU1 ICs5OCw1NCBAQA0KIHN0YXRpYwlidXNfZG1hbWFwX3QJb3ZlcnJ1bl9kbWFt YXA7DQogc3RhdGljCWJ1c19hZGRyX3QJb3ZlcnJ1bl9waHlzYmFzZTsNCiAN Ci1zdGF0aWMgc3RydWN0ICBwY2lfZGV2aWNlIGFkdl9wY2lfZHJpdmVyID0g ew0KLQkiYWR2IiwNCi0gICAgICAgIGFkdnBjaXByb2JlLA0KLSAgICAgICAg YWR2cGNpYXR0YWNoLA0KLSAgICAgICAgJmFkdl91bml0LA0KLQlOVUxMDQot fTsNCi0NCi1DT01QQVRfUENJX0RSSVZFUiAoYWR2X3BjaSwgYWR2X3BjaV9k cml2ZXIpOw0KLQ0KLXN0YXRpYyBjb25zdCBjaGFyKg0KLWFkdnBjaXByb2Jl KHBjaWNpX3QgdGFnLCBwY2lkaV90IHR5cGUpDQorc3RhdGljIGludA0KK2Fk dl9wY2lfcHJvYmUoZGV2aWNlX3QgZGV2KQ0KIHsNCi0JaW50IHJldjsNCisJ aW50CXJldiA9IHBjaV9nZXRfcmV2aWQoZGV2KTsNCiANCi0JcmV2ID0gcGNp X2NvbmZfcmVhZCh0YWcsIFBDSV9DTEFTU19SRUcpICYgUENJX1JFVklTSU9O X01BU0s7DQotCXN3aXRjaCAodHlwZSkgew0KKwlzd2l0Y2ggKHBjaV9nZXRf ZGV2aWQoZGV2KSkgew0KIAljYXNlIFBDSV9ERVZJQ0VfSURfQURWQU5TWVNf MTIwMEE6DQotCQlyZXR1cm4gKCJBZHZhblN5cyBBU0MxMjAwQSBTQ1NJIGNv bnRyb2xsZXIiKTsNCisJCWRldmljZV9zZXRfZGVzYyhkZXYsICJBZHZhblN5 cyBBU0MxMjAwQSBTQ1NJIGNvbnRyb2xsZXIiKTsNCisJCXJldHVybiAwOw0K IAljYXNlIFBDSV9ERVZJQ0VfSURfQURWQU5TWVNfMTIwMEI6DQotCQlyZXR1 cm4gKCJBZHZhblN5cyBBU0MxMjAwQiBTQ1NJIGNvbnRyb2xsZXIiKTsNCisJ CWRldmljZV9zZXRfZGVzYyhkZXYsICJBZHZhblN5cyBBU0MxMjAwQiBTQ1NJ IGNvbnRyb2xsZXIiKTsNCisJCXJldHVybiAwOw0KIAljYXNlIFBDSV9ERVZJ Q0VfSURfQURWQU5TWVNfMzAwMDoNCi0JCWlmIChyZXYgPT0gUENJX0RFVklD RV9SRVZfQURWQU5TWVNfMzE1MCkNCi0JCQlyZXR1cm4gKCJBZHZhblN5cyBB U0MzMTUwIFNDU0kgY29udHJvbGxlciIpOw0KLQkJZWxzZSBpZiAocmV2ID09 IFBDSV9ERVZJQ0VfUkVWX0FEVkFOU1lTXzMwNTApDQotCQkJcmV0dXJuICgi QWR2YW5TeXMgQVNDMzAzMC81MCBTQ1NJIGNvbnRyb2xsZXIiKTsNCi0JCWVs c2UgaWYgKHJldiA+PSBQQ0lfREVWSUNFX1JFVl9BRFZBTlNZU18zMTUwKQ0K LQkJCXJldHVybiAoIlVua25vd24gQWR2YW5TeXMgY29udHJvbGxlciIpOw0K KwkJaWYgKHJldiA9PSBQQ0lfREVWSUNFX1JFVl9BRFZBTlNZU18zMTUwKSB7 DQorCQkJZGV2aWNlX3NldF9kZXNjKGRldiwNCisJCQkJCSJBZHZhblN5cyBB U0MzMTUwIFNDU0kgY29udHJvbGxlciIpOw0KKwkJCXJldHVybiAwOw0KKwkJ fSBlbHNlIGlmIChyZXYgPT0gUENJX0RFVklDRV9SRVZfQURWQU5TWVNfMzA1 MCkgew0KKwkJCWRldmljZV9zZXRfZGVzYyhkZXYsDQorCQkJCQkiQWR2YW5T eXMgQVNDMzAzMC81MCBTQ1NJIGNvbnRyb2xsZXIiKTsNCisJCQlyZXR1cm4g MDsNCisJCX0gZWxzZSBpZiAocmV2ID49IFBDSV9ERVZJQ0VfUkVWX0FEVkFO U1lTXzMxNTApIHsNCisJCQlkZXZpY2Vfc2V0X2Rlc2MoZGV2LCAiVW5rbm93 biBBZHZhblN5cyBjb250cm9sbGVyIik7DQorCQkJcmV0dXJuIDA7DQorCQl9 DQogCQlicmVhazsNCiAJZGVmYXVsdDoNCiAJCWJyZWFrOw0KIAl9DQotCXJl dHVybiAoTlVMTCk7DQorCXJldHVybiBFTlhJTzsNCiB9DQogDQotc3RhdGlj IHZvaWQNCi1hZHZwY2lhdHRhY2gocGNpY2lfdCBjb25maWdfaWQsIGludCB1 bml0KQ0KK3N0YXRpYyBpbnQNCithZHZfcGNpX2F0dGFjaChkZXZpY2VfdCBk ZXYpDQogew0KLQl1X2ludDE2X3QJaW9fcG9ydDsNCiAJc3RydWN0CQlhZHZf c29mdGMgKmFkdjsNCiAJdV9pbnQzMl90CWlkOw0KIAl1X2ludDMyX3QJY29t bWFuZDsNCiAJaW50CQllcnJvcjsNCi0gDQorCWludAkJcmlkID0gMDsNCisJ dm9pZAkJKmloOw0KKwlzdHJ1Y3QgcmVzb3VyY2UJKmlvcmVzLCAqaXJxcmVz Ow0KKw0KIAkvKg0KIAkgKiBEZXRlcm1pbmUgdGhlIGNoaXAgdmVyc2lvbi4N CiAJICovDQotCWlkID0gcGNpX2NmZ3JlYWQoY29uZmlnX2lkLCBQQ0lfSURf UkVHLCAvKmJ5dGVzKi80KTsNCi0JY29tbWFuZCA9IHBjaV9jZmdyZWFkKGNv bmZpZ19pZCwgUENJUl9DT01NQU5ELCAvKmJ5dGVzKi8xKTsNCisJaWQgPSBw Y2lfcmVhZF9jb25maWcoZGV2LCBQQ0lfSURfUkVHLCAvKmJ5dGVzKi80KTsN CisJY29tbWFuZCA9IHBjaV9yZWFkX2NvbmZpZyhkZXYsIFBDSVJfQ09NTUFO RCwgLypieXRlcyovMSk7DQogDQogCS8qDQogCSAqIFRoZXNlIGNhcmRzIGRv IG5vdCBhbGxvdyBtZW1vcnkgbWFwcGVkIGFjY2Vzc2VzLCBzbyB3ZSBtdXN0 DQpAQCAtMTUzLDcgKzE1NSw3IEBADQogCWlmICgoY29tbWFuZCAmIChQQ0lN X0NNRF9QT1JURU58UENJTV9DTURfQlVTTUFTVEVSRU4pKQ0KIAkgIT0gKFBD SU1fQ01EX1BPUlRFTnxQQ0lNX0NNRF9CVVNNQVNURVJFTikpIHsNCiAJCWNv bW1hbmQgfD0gUENJTV9DTURfUE9SVEVOfFBDSU1fQ01EX0JVU01BU1RFUkVO Ow0KLQkJcGNpX2NmZ3dyaXRlKGNvbmZpZ19pZCwgUENJUl9DT01NQU5ELCBj b21tYW5kLCAvKmJ5dGVzKi8xKTsNCisJCXBjaV93cml0ZV9jb25maWcoZGV2 LCBQQ0lSX0NPTU1BTkQsIGNvbW1hbmQsIC8qYnl0ZXMqLzEpOw0KIAl9DQog DQogCS8qDQpAQCAtMTYxLDE5ICsxNjMsMjEgQEANCiAJICovDQogCWlmIChp ZCA9PSBQQ0lfREVWSUNFX0lEX0FEVkFOU1lTXzEyMDBBDQogCSB8fCBpZCA9 PSBQQ0lfREVWSUNFX0lEX0FEVkFOU1lTXzEyMDBCKSB7DQotCQlwY2lfY2Zn d3JpdGUoY29uZmlnX2lkLCBQQ0lSX0xBVFRJTUVSLCAvKnZhbHVlKi8wLCAv KmJ5dGVzKi8xKTsNCisJCXBjaV93cml0ZV9jb25maWcoZGV2LCBQQ0lSX0xB VFRJTUVSLCAvKnZhbHVlKi8wLCAvKmJ5dGVzKi8xKTsNCiAJfQ0KLQ0KIA0K LQlpZiAocGNpX21hcF9wb3J0KGNvbmZpZ19pZCwgUENJX0JBU0VBRFIwLCAm aW9fcG9ydCkgPT0gMCkNCi0JCXJldHVybjsNCisJaW9yZXMgPSBidXNfYWxs b2NfcmVzb3VyY2UoZGV2LCBTWVNfUkVTX0lPUE9SVCwgJnJpZCwgMCwgfjAs IDEsDQorCQkJCSAgIFJGX0FDVElWRSk7DQorCWlmIChpb3JlcyA9PSBOVUxM KQ0KKwkJcmV0dXJuIEVOWElPOw0KIA0KLQlpZiAoYWR2X2ZpbmRfc2lnbmF0 dXJlKEkzODZfQlVTX1NQQUNFX0lPLCBpb19wb3J0KSA9PSAwKQ0KLQkJcmV0 dXJuOw0KKwlpZiAoYWR2X2ZpbmRfc2lnbmF0dXJlKHJtYW5fZ2V0X2J1c3Rh Zyhpb3JlcyksDQorCQkJICAgICAgIHJtYW5fZ2V0X2J1c2hhbmRsZShpb3Jl cykpID09IDApDQorCQlyZXR1cm4gRU5YSU87DQogDQotCWFkdiA9IGFkdl9h bGxvYyh1bml0LCBJMzg2X0JVU19TUEFDRV9JTywgaW9fcG9ydCk7DQorCWFk diA9IGFkdl9hbGxvYyhkZXYsIHJtYW5fZ2V0X2J1c3RhZyhpb3JlcyksIHJt YW5fZ2V0X2J1c2hhbmRsZShpb3JlcykpOw0KIAlpZiAoYWR2ID09IE5VTEwp DQotCQlyZXR1cm47DQorCQlyZXR1cm4gRU5YSU87DQogDQogCS8qIEFsbG9j YXRlIGEgZG1hdGFnIGZvciBvdXIgdHJhbnNmZXIgRE1BIG1hcHMgKi8NCiAJ LyogWFhYIFNob3VsZCBiZSBhIGNoaWxkIG9mIHRoZSBQQ0kgYnVzIGRtYSB0 YWcgKi8NCkBAIC0xOTIsNyArMTk2LDcgQEANCiAJCXByaW50ZigiJXM6IENv dWxkIG5vdCBhbGxvY2F0ZSBETUEgdGFnIC0gZXJyb3IgJWRcbiIsDQogCQkg ICAgICAgYWR2X25hbWUoYWR2KSwgZXJyb3IpOw0KIAkJYWR2X2ZyZWUoYWR2 KTsNCi0JCXJldHVybjsNCisJCXJldHVybiBFTlhJTzsNCiAJfQ0KIA0KIAlh ZHYtPmluaXRfbGV2ZWwrKzsNCkBAIC0yMDgsNyArMjEyLDcgQEANCiAJCQkJ ICAgICAgICZvdmVycnVuX2RtYXQpICE9IDApIHsNCiAJCQlidXNfZG1hX3Rh Z19kZXN0cm95KGFkdi0+cGFyZW50X2RtYXQpOw0KIAkJCWFkdl9mcmVlKGFk dik7DQotCQkJcmV0dXJuOw0KKwkJCXJldHVybiBFTlhJTzsNCiAgICAgICAg CQl9DQogCQlpZiAoYnVzX2RtYW1lbV9hbGxvYyhvdmVycnVuX2RtYXQsDQog CQkJCSAgICAgKHZvaWQgKiopJm92ZXJydW5fYnVmLA0KQEAgLTIxNyw3ICsy MjEsNyBAQA0KIAkJCWJ1c19kbWFfdGFnX2Rlc3Ryb3kob3ZlcnJ1bl9kbWF0 KTsNCiAJCQlidXNfZG1hX3RhZ19kZXN0cm95KGFkdi0+cGFyZW50X2RtYXQp Ow0KIAkJCWFkdl9mcmVlKGFkdik7DQotCQkJcmV0dXJuOw0KKwkJCXJldHVy biBFTlhJTzsNCiAJCX0NCiAJCS8qIEFuZCBwZXJtYW5lbnRseSBtYXAgaXQg aW4gKi8gIA0KIAkJYnVzX2RtYW1hcF9sb2FkKG92ZXJydW5fZG1hdCwgb3Zl cnJ1bl9kbWFtYXAsDQpAQCAtMjU0LDcgKzI1OCw3IEBADQogDQogCWlmIChh ZHZfaW5pdChhZHYpICE9IDApIHsNCiAJCWFkdl9mcmVlKGFkdik7DQotCQly ZXR1cm47DQorCQlyZXR1cm4gRU5YSU87DQogCX0NCiANCiAJYWR2LT5tYXhf ZG1hX2NvdW50ID0gQURWX1BDSV9NQVhfRE1BX0NPVU5UOw0KQEAgLTI3Nywx MCArMjgxLDI4IEBADQogCQlhZHYtPmZpeF9hc3luX3hmZXIgPSB+MDsNCiAJ fQ0KIA0KLQlpZiAoKHBjaV9tYXBfaW50KGNvbmZpZ19pZCwgYWR2X2ludHIs ICh2b2lkICopYWR2LCAmY2FtX2ltYXNrKSkgPT0gMCkgew0KKwlpcnFyZXMg PSBidXNfYWxsb2NfcmVzb3VyY2UoZGV2LCBTWVNfUkVTX0lSUSwgJnJpZCwg MCwgfjAsIDEsDQorCQkJCSAgICBSRl9TSEFSRUFCTEUgfCBSRl9BQ1RJVkUp Ow0KKwlpZiAoaXJxcmVzID09IE5VTEwgfHwNCisJICAgIGJ1c19zZXR1cF9p bnRyKGRldiwgaXJxcmVzLCBJTlRSX1RZUEVfQ0FNLCBhZHZfaW50ciwgYWR2 LCAmaWgpKSB7DQogCQlhZHZfZnJlZShhZHYpOw0KLQkJcmV0dXJuOw0KKwkJ cmV0dXJuIEVOWElPOw0KIAl9DQotCQ0KKw0KIAlhZHZfYXR0YWNoKGFkdik7 DQorCXJldHVybiAwOw0KIH0NCisNCitzdGF0aWMgZGV2aWNlX21ldGhvZF90 IGFkdl9wY2lfbWV0aG9kc1tdID0gew0KKwkvKiBEZXZpY2UgaW50ZXJmYWNl ICovDQorCURFVk1FVEhPRChkZXZpY2VfcHJvYmUsCQlhZHZfcGNpX3Byb2Jl KSwNCisJREVWTUVUSE9EKGRldmljZV9hdHRhY2gsCWFkdl9wY2lfYXR0YWNo KSwNCisJeyAwLCAwIH0NCit9Ow0KKw0KK3N0YXRpYyBkcml2ZXJfdCBhZHZf cGNpX2RyaXZlciA9IHsNCisJImFkdiIsIGFkdl9wY2lfbWV0aG9kcywgc2l6 ZW9mKHN0cnVjdCBhZHZfc29mdGMpDQorfTsNCisNCitzdGF0aWMgZGV2Y2xh c3NfdCBhZHZfcGNpX2RldmNsYXNzOw0KK0RSSVZFUl9NT0RVTEUoYWR2LCBw Y2ksIGFkdl9wY2lfZHJpdmVyLCBhZHZfcGNpX2RldmNsYXNzLCAwLCAwKTsN CkluZGV4OiBzeXMvZGV2L2FkdmFuc3lzL2FkdmFuc3lzLmMNCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMv ZGV2L2FkdmFuc3lzL2FkdmFuc3lzLmMsdg0KcmV0cmlldmluZyByZXZpc2lv biAxLjE0DQpkaWZmIC11IC1yMS4xNCBhZHZhbnN5cy5jDQotLS0gc3lzL2Rl di9hZHZhbnN5cy9hZHZhbnN5cy5jCTIwMDAvMDIvMDEgMDA6NDM6NTgJMS4x NA0KKysrIHN5cy9kZXYvYWR2YW5zeXMvYWR2YW5zeXMuYwkyMDAwLzAzLzMx IDEwOjA3OjI1DQpAQCAtNTYsNiArNTYsOSBAQA0KICNpbmNsdWRlIDxtYWNo aW5lL2J1c19waW8uaD4NCiAjaW5jbHVkZSA8bWFjaGluZS9idXMuaD4NCiAj aW5jbHVkZSA8bWFjaGluZS9jbG9jay5oPg0KKyNpbmNsdWRlIDxtYWNoaW5l L3Jlc291cmNlLmg+DQorI2luY2x1ZGUgPHN5cy9idXMuaD4gDQorI2luY2x1 ZGUgPHN5cy9ybWFuLmg+IA0KIA0KICNpbmNsdWRlIDxjYW0vY2FtLmg+DQog I2luY2x1ZGUgPGNhbS9jYW1fY2NiLmg+DQpAQCAtNzMsOCArNzYsNiBAQA0K IA0KICNpbmNsdWRlIDxkZXYvYWR2YW5zeXMvYWR2YW5zeXMuaD4NCiANCi11 X2xvbmcgYWR2X3VuaXQ7DQotDQogc3RhdGljIHZvaWQJYWR2X2FjdGlvbihz dHJ1Y3QgY2FtX3NpbSAqc2ltLCB1bmlvbiBjY2IgKmNjYik7DQogc3RhdGlj IHZvaWQJYWR2X2V4ZWN1dGVfY2NiKHZvaWQgKmFyZywgYnVzX2RtYV9zZWdt ZW50X3QgKmRtX3NlZ3MsDQogCQkJCWludCBuc2VnbWVudHMsIGludCBlcnJv cik7DQpAQCAtOTIsOCArOTMsNiBAQA0KIHN0YXRpYyBfX2lubGluZSB2b2lk IGFkdl9jbGVhcl9zdGF0ZShzdHJ1Y3QgYWR2X3NvZnRjICphZHYsIHVuaW9u IGNjYiogY2NiKTsNCiBzdGF0aWMgdm9pZCBhZHZfY2xlYXJfc3RhdGVfcmVh bGx5KHN0cnVjdCBhZHZfc29mdGMgKmFkdiwgdW5pb24gY2NiKiBjY2IpOw0K IA0KLXN0cnVjdCBhZHZfc29mdGMgKmFkdnNvZnRjc1tOQURWXTsgICAvKiBY WFggQ29uZmlnIHNob3VsZCBoYW5kbGUgdGhpcyAqLw0KLQ0KIHN0YXRpYyBf X2lubGluZSBzdHJ1Y3QgYWR2X2NjYl9pbmZvICoNCiBhZHZfZ2V0X2NjYl9p bmZvKHN0cnVjdCBhZHZfc29mdGMgKmFkdikNCiB7DQpAQCAtNzI5LDMzICs3 MjgsMTcgQEANCiB9DQogDQogc3RydWN0IGFkdl9zb2Z0YyAqDQotYWR2X2Fs bG9jKGludCB1bml0LCBidXNfc3BhY2VfdGFnX3QgdGFnLCBidXNfc3BhY2Vf aGFuZGxlX3QgYnNoKQ0KK2Fkdl9hbGxvYyhkZXZpY2VfdCBkZXYsIGJ1c19z cGFjZV90YWdfdCB0YWcsIGJ1c19zcGFjZV9oYW5kbGVfdCBic2gpDQogew0K LQlzdHJ1Y3QJIGFkdl9zb2Z0YyAqYWR2Ow0KLSAgIA0KLQlpZiAodW5pdCA+ PSBOQURWKSB7DQotCQlwcmludGYoImFkdjogdW5pdCBudW1iZXIgKCVkKSB0 b28gaGlnaFxuIiwgdW5pdCk7DQotCQlyZXR1cm4gTlVMTDsNCi0JfQ0KKwlz dHJ1Y3QgYWR2X3NvZnRjICphZHYgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7 DQogDQogCS8qDQogCSAqIEFsbG9jYXRlIGEgc3RvcmFnZSBhcmVhIGZvciB1 cw0KIAkgKi8NCi0JaWYgKGFkdnNvZnRjc1t1bml0XSkgew0KLQkJcHJpbnRm KCJhZHYlZDogbWVtb3J5IGFscmVhZHkgYWxsb2NhdGVkXG4iLCB1bml0KTsN Ci0JCXJldHVybiBOVUxMOw0KLQl9DQotDQotCWFkdiA9IG1hbGxvYyhzaXpl b2Yoc3RydWN0IGFkdl9zb2Z0YyksIE1fREVWQlVGLCBNX05PV0FJVCk7DQot CWlmICghYWR2KSB7DQotCQlwcmludGYoImFkdiVkOiBjYW5ub3QgbWFsbG9j IVxuIiwgdW5pdCk7DQotCQlyZXR1cm4gTlVMTDsNCi0JfQ0KLQliemVybyhh ZHYsIHNpemVvZihzdHJ1Y3QgYWR2X3NvZnRjKSk7DQogCUxJU1RfSU5JVCgm YWR2LT5wZW5kaW5nX2NjYnMpOw0KIAlTTElTVF9JTklUKCZhZHYtPmZyZWVf Y2NiX2luZm9zKTsNCi0JYWR2c29mdGNzW3VuaXRdID0gYWR2Ow0KLQlhZHYt PnVuaXQgPSB1bml0Ow0KKwlhZHYtPmRldiA9IGRldjsNCisJYWR2LT51bml0 ID0gZGV2aWNlX2dldF91bml0KGRldik7DQogCWFkdi0+dGFnID0gdGFnOw0K IAlhZHYtPmJzaCA9IGJzaDsNCiANCkBAIC03OTEsNyArNzc0LDYgQEANCiAJ Y2FzZSAwOg0KIAkJYnJlYWs7DQogCX0NCi0JZnJlZShhZHYsIE1fREVWQlVG KTsNCiB9DQogDQogaW50DQpJbmRleDogc3lzL2Rldi9hZHZhbnN5cy9hZHZh bnN5cy5oDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hv bWUvbmN2cy9zcmMvc3lzL2Rldi9hZHZhbnN5cy9hZHZhbnN5cy5oLHYNCnJl dHJpZXZpbmcgcmV2aXNpb24gMS4yDQpkaWZmIC11IC1yMS4yIGFkdmFuc3lz LmgNCi0tLSBzeXMvZGV2L2FkdmFuc3lzL2FkdmFuc3lzLmgJMTk5OS8wOC8y OCAwMDo0MToxNgkxLjINCisrKyBzeXMvZGV2L2FkdmFuc3lzL2FkdmFuc3lz LmgJMjAwMC8wMy8zMSAwOTozNzozMw0KQEAgLTM2LDEwICszNiw5IEBADQog I2lmbmRlZiBfQURWQU5TWVNfSF8NCiAjZGVmaW5lIF9BRFZBTlNZU19IXw0K IA0KLSNpbmNsdWRlICJhZHYuaCINCiAjaW5jbHVkZSA8ZGV2L2FkdmFuc3lz L2FkdmxpYi5oPg0KIA0KLXN0cnVjdCBhZHZfc29mdGMgKglhZHZfYWxsb2Mo aW50IHVuaXQsIGJ1c19zcGFjZV90YWdfdCB0YWcsDQorc3RydWN0IGFkdl9z b2Z0YyAqCWFkdl9hbGxvYyhkZXZpY2VfdCBkZXYsIGJ1c19zcGFjZV90YWdf dCB0YWcsDQogCQkJCSAgYnVzX3NwYWNlX2hhbmRsZV90IGJzaCk7DQogY2hh ciAqCQkJYWR2X25hbWUoc3RydWN0IGFkdl9zb2Z0YyAqYWR2KTsNCiB2b2lk CQkJYWR2X21hcCh2b2lkICphcmcsIGJ1c19kbWFfc2VnbWVudF90ICpzZWdz LA0KQEAgLTUzLDcgKzUyLDQgQEANCiAJCQkJIHVfaW50IHNjc2lfc3RhdCwg dV9pbnQgcV9ubyk7DQogdGltZW91dF90CQlhZHZfdGltZW91dDsNCiANCi1l eHRlcm4gc3RydWN0IGFkdl9zb2Z0YyAqYWR2c29mdGNzW05BRFZdOyAgIC8q IFhYWCBDb25maWcgc2hvdWxkIGhhbmRsZSB0aGlzICovDQotDQotZXh0ZXJu IHVfbG9uZyBhZHZfdW5pdDsNCiAjZW5kaWYgLyogX0FEVkFOU1lTX0hfICov DQpJbmRleDogc3lzL2Rldi9hZHZhbnN5cy9hZHZsaWIuYw0KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5cy9k ZXYvYWR2YW5zeXMvYWR2bGliLmMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAx LjE1DQpkaWZmIC11IC1yMS4xNSBhZHZsaWIuYw0KLS0tIHN5cy9kZXYvYWR2 YW5zeXMvYWR2bGliLmMJMjAwMC8wMS8xNCAwMzozMzozNwkxLjE1DQorKysg c3lzL2Rldi9hZHZhbnN5cy9hZHZsaWIuYwkyMDAwLzAzLzI5IDEyOjA2OjEx DQpAQCAtNTAsNiArNTAsOSBAQA0KICNpbmNsdWRlIDxtYWNoaW5lL2J1c19w aW8uaD4NCiAjaW5jbHVkZSA8bWFjaGluZS9idXMuaD4NCiAjaW5jbHVkZSA8 bWFjaGluZS9jbG9jay5oPg0KKyNpbmNsdWRlIDxtYWNoaW5lL3Jlc291cmNl Lmg+DQorI2luY2x1ZGUgPHN5cy9idXMuaD4gDQorI2luY2x1ZGUgPHN5cy9y bWFuLmg+IA0KIA0KICNpbmNsdWRlIDxjYW0vY2FtLmg+DQogI2luY2x1ZGUg PGNhbS9jYW1fY2NiLmg+DQpJbmRleDogc3lzL2Rldi9hZHZhbnN5cy9hZHZs aWIuaA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9ob21l L25jdnMvc3JjL3N5cy9kZXYvYWR2YW5zeXMvYWR2bGliLmgsdg0KcmV0cmll dmluZyByZXZpc2lvbiAxLjgNCmRpZmYgLXUgLXIxLjggYWR2bGliLmgNCi0t LSBzeXMvZGV2L2FkdmFuc3lzL2FkdmxpYi5oCTIwMDAvMDEvMTQgMDM6MzM6 MzgJMS44DQorKysgc3lzL2Rldi9hZHZhbnN5cy9hZHZsaWIuaAkyMDAwLzAz LzMxIDA5OjU5OjQ2DQpAQCAtNDkyLDggKzQ5Miw4IEBADQogCXN0cnVjdCBh ZHZfdHJhbnNpbmZvIHVzZXI7DQogfTsNCiANCi1zdHJ1Y3QgYWR2X3NvZnRj DQotew0KK3N0cnVjdCBhZHZfc29mdGMgew0KKwlkZXZpY2VfdAkJZGV2Ow0K IAlidXNfc3BhY2VfdGFnX3QJCSB0YWc7DQogCWJ1c19zcGFjZV9oYW5kbGVf dAkgYnNoOw0KIAlzdHJ1Y3QgY2FtX3NpbQkJKnNpbTsNCkluZGV4OiBzeXMv ZGV2L2FkdmFuc3lzL2Fkd2xpYi5jDQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL2Rldi9hZHZhbnN5cy9h ZHdsaWIuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNg0KZGlmZiAtdSAt cjEuNiBhZHdsaWIuYw0KLS0tIHN5cy9kZXYvYWR2YW5zeXMvYWR3bGliLmMJ MjAwMC8wMy8wMiAwMDowODozNQkxLjYNCisrKyBzeXMvZGV2L2FkdmFuc3lz L2Fkd2xpYi5jCTIwMDAvMDMvMzEgMTA6MTg6MzQNCkBAIC01NCw2ICs1NCw5 IEBADQogI2luY2x1ZGUgPG1hY2hpbmUvY2xvY2suaD4NCiANCiAjaW5jbHVk ZSA8Y2FtL2NhbS5oPg0KKyNpbmNsdWRlIDxjYW0vY2FtX2NjYi5oPg0KKyNp bmNsdWRlIDxjYW0vY2FtX3NpbS5oPg0KKyNpbmNsdWRlIDxjYW0vY2FtX3hw dF9zaW0uaD4NCiAjaW5jbHVkZSA8Y2FtL3Njc2kvc2NzaV9hbGwuaD4NCiAN CiAjaW5jbHVkZSA8ZGV2L2FkdmFuc3lzL2Fkd2xpYi5oPg0KSW5kZXg6IHN5 cy9pMzg2L2lzYS9pc2FfY29tcGF0LmgNCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMvaTM4Ni9pc2EvaXNh X2NvbXBhdC5oLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4zNA0KZGlmZiAt dSAtcjEuMzQgaXNhX2NvbXBhdC5oDQotLS0gc3lzL2kzODYvaXNhL2lzYV9j b21wYXQuaAkyMDAwLzAzLzMwIDA1OjE2OjAxCTEuMzQNCisrKyBzeXMvaTM4 Ni9pc2EvaXNhX2NvbXBhdC5oCTIwMDAvMDMvMzEgMTA6MTQ6MDkNCkBAIC0y Nyw3ICsyNyw2IEBADQogICovDQogDQogI2luY2x1ZGUgInZ0LmgiDQotI2lu Y2x1ZGUgImFkdi5oIg0KICNpbmNsdWRlICJhci5oIg0KICNpbmNsdWRlICJj eC5oIg0KICNpbmNsdWRlICJlbC5oIg0KQEAgLTc5LDcgKzc4LDYgQEANCiB9 Ow0KIA0KIGV4dGVybiBzdHJ1Y3QgaXNhX2RyaXZlciAgdnRkcml2ZXI7DQot ZXh0ZXJuIHN0cnVjdCBpc2FfZHJpdmVyIGFkdmRyaXZlcjsNCiBleHRlcm4g c3RydWN0IGlzYV9kcml2ZXIgIGFyZHJpdmVyOw0KIGV4dGVybiBzdHJ1Y3Qg aXNhX2RyaXZlciAgY3hkcml2ZXI7DQogZXh0ZXJuIHN0cnVjdCBpc2FfZHJp dmVyICBlbGRyaXZlcjsNCkBAIC0yMjYsMTggKzIyNCw2IEBADQogI2VuZGlm DQogI2lmIE5USU5BID4gMA0KIAl7IElOVFJfVFlQRV9ORVQsICZ0aW5hZHJp dmVyIH0sDQotI2VuZGlmDQotDQotLyogQ0FNICovDQotDQotI2lmIE5BRFYg PiAwDQotCXsgSU5UUl9UWVBFX0NBTSwgJmFkdmRyaXZlciB9LA0KLSNlbmRp Zg0KLQ0KLSNpZmRlZiBQQzk4DQotI2lmIE5CUyA+IDANCi0JeyBJTlRSX1RZ UEVfQ0FNLCAmYnNkcml2ZXIgfSwNCi0jZW5kaWYNCiAjZW5kaWYNCiANCiAv KiBNSVNDICovDQpJbmRleDogc3lzL3BjOTgvcGM5OC9pc2FfY29tcGF0LmgN Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvaG9tZS9uY3Zz L3NyYy9zeXMvcGM5OC9wYzk4L2lzYV9jb21wYXQuaCx2DQpyZXRyaWV2aW5n IHJldmlzaW9uIDEuMTUNCmRpZmYgLXUgLXIxLjE1IGlzYV9jb21wYXQuaA0K LS0tIHN5cy9wYzk4L3BjOTgvaXNhX2NvbXBhdC5oCTIwMDAvMDMvMzAgMDU6 MTY6MDYJMS4xNQ0KKysrIHN5cy9wYzk4L3BjOTgvaXNhX2NvbXBhdC5oCTIw MDAvMDMvMzEgMTA6MTQ6MjcNCkBAIC0yNyw3ICsyNyw2IEBADQogICovDQog DQogI2luY2x1ZGUgInZ0LmgiDQotI2luY2x1ZGUgImFkdi5oIg0KICNpbmNs dWRlICJ3ZGMuaCINCiAjaW5jbHVkZSAiYXIuaCINCiAjaW5jbHVkZSAiY3gu aCINCkBAIC04NSw3ICs4NCw2IEBADQogfTsNCiANCiBleHRlcm4gc3RydWN0 IGlzYV9kcml2ZXIgIHZ0ZHJpdmVyOw0KLWV4dGVybiBzdHJ1Y3QgaXNhX2Ry aXZlciBhZHZkcml2ZXI7DQogZXh0ZXJuIHN0cnVjdCBpc2FfZHJpdmVyIHdk Y2RyaXZlcjsNCiBleHRlcm4gc3RydWN0IGlzYV9kcml2ZXIgIGFyZHJpdmVy Ow0KIGV4dGVybiBzdHJ1Y3QgaXNhX2RyaXZlciAgY3hkcml2ZXI7DQpAQCAt MjQ3LDEyICsyNDUsNiBAQA0KICNlbmRpZg0KIA0KIC8qIENBTSAqLw0KLQ0K LSNpZm5kZWYgUEM5OA0KLSNpZiBOQURWID4gMA0KLQl7IElOVFJfVFlQRV9D QU0sICZhZHZkcml2ZXIgfSwNCi0jZW5kaWYNCi0jZW5kaWYNCiANCiAjaWZk ZWYgUEM5OA0KICNpZiBOQlMgPiAwDQo= --673024-1863453750-960878988=:5729-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 13 7:45: 9 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from front6m.grolier.fr (front6m.grolier.fr [195.36.216.56]) by hub.freebsd.org (Postfix) with ESMTP id E8FF437B795; Tue, 13 Jun 2000 07:44:59 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from ppp-159-197.villette.club-internet.fr (ppp-159-197.villette.club-internet.fr [195.36.159.197]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA11902; Tue, 13 Jun 2000 16:44:11 +0200 (MET DST) Date: Tue, 13 Jun 2000 16:21:31 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: "Bradley T. Hughes" Cc: freebsd-stable@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Problem with newer sym driver on a Tekram DC-390U2W controller In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, Thanks for the report and sorry for the breakage. Unfortunately I haven't any Tekram board and so, risk of device setup breakage is more likely to happen for these boards due to their proprietary NVRAM layout. Tekram use to speak highly of their success under notably Linux and seem to want to provide their own drivers. May-be, for this reason, they never sent me any of their SYM53C8XX based SCSI boards for driver testing. Well. I have an explanation of the breakage. The table used by the driver to translate the NVRAM sync. tag to sync. factor is probably wrong. The values seem to be rather ((sync. period)/4 in nano-seconds) than true SCSI sync. factors. Here it the offending table: static u_char Tekram_sync[16] = {25,31,37,43, 50,62,75,125, 12,15,18,21, 6,7,9,10}; The below preliminar patch should work-around the problem: --- sym_hipd.c.0613 Tue Jun 13 14:58:18 2000 +++ sym_hipd.c Tue Jun 13 15:17:54 2000 @@ -2960,11 +2960,15 @@ sym_nvram_setup_target (np, i, nvram); /* - * For now, guess PPR support from the period. + * For now, guess PPR/DT support from the period + * and BUS width. */ - if (tp->tinfo.user.period <= 9) { - tp->tinfo.user.options |= PPR_OPT_DT; - tp->tinfo.user.offset = np->maxoffs_dt; + if (np->features & FE_ULTRA3) { + if (tp->tinfo.user.period <= 9 && + tp->tinfo.user.width == BUS_16_BIT) { + tp->tinfo.user.options |= PPR_OPT_DT; + tp->tinfo.user.offset = np->maxoffs_dt; + } } if (!tp->usrtags) ----------------------- Cut there ---------------------- Note that the driver was probably trusting too much the NVRAM content. :) The code should have been more careful. I will prepare and commit a complete fix very soon. On Sat, 10 Jun 2000, Bradley T. Hughes wrote: > My system at work has on of the mentioned controllers, which uses a > Symbios 53C895 chip. > > I installed FreeBSD 4.0-RELEASE on the machine when I got the box, and was > happy to see that da0 reported 40mb/s transfer rates. > > Soon after I cvsup'ed to -STABLE, which had an updated sym driver (1.5.3 > from May 06), and my disk performance dropped dramatically. Upon > investigation, I noticed that da0 was reporting only 6.6mb/s transfer > rates. > > I began looking through mailing list archives and have found no posts even > resembling the problem that I have... so I decided to try something. I > found sym driver 1.3.2, dropped it into /usr/src/sys/dev/sym and > recompiled my kernel. Upon reboot, da0 reported 40mb/s xfer rates and my > disk performance came back to "normal" (read: what i was getting after > setting upthe machine) > > I repeated this process for sym driver versions 1.4.1 and 1.5.0, both of > which work beautifully. But driver 1.5.3 does not, and driver 1.6.1 from > -CURRENT does not. > > Is there something I could add to my kernel config to get the original > performance out of the current driver in -STABLE? > > I have attached a few dmesg logs, and will gladly provide other > information if necessary. If you have time for doing the following tests, this would allow me to fix correctly the Tekram NVRAM sync. table: 1) Use latest sym-1.6.1 driver (for 4.0 just steal driver files from -current) (You may patch it prior to do the tests, but it is not required) 2) Edit sym_hipd.c and add the following 'define' at the beginning of the source: #define SYM_CONF_DEBUG_NVRAM (Or add -DSYM_CONF_DEBUG_NVRAM to the compilation options) 3) Starting with 20 Mega-transfers per second until maximum possible, try successivelly several sync. speeds (all values if only the 4 possible discrete values are allowed) from the NVRAM and send me the driver boot messages. If you have several SCSI devices, using different values for each device can cover the sync. value range in a fiew runs. Thanks in advance, Regards, Gerard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 13 8:25:10 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from front7m.grolier.fr (front7m.grolier.fr [195.36.216.57]) by hub.freebsd.org (Postfix) with ESMTP id B6F2C37BEBD; Tue, 13 Jun 2000 08:24:58 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from ppp-109-219.villette.club-internet.fr (ppp-109-219.villette.club-internet.fr [194.158.109.219]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA04686; Tue, 13 Jun 2000 17:24:50 +0200 (MET DST) Date: Tue, 13 Jun 2000 17:01:40 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: "Bradley T. Hughes" Cc: freebsd-stable@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Problem with newer sym driver on a Tekram DC-390U2W controller In-Reply-To: Message-ID: 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 X-Loop: FreeBSD.org I just downloaded the latest Tekram driver sources for FreeBSD-4.0 and the files contains all information I need about the sync. table. Thus, the below testing are no longer needed. Regards, G=E9rard. On Tue, 13 Jun 2000, G=E9rard Roudier wrote: [ ... ] > > I have attached a few dmesg logs, and will gladly provide other > > information if necessary. >=20 > If you have time for doing the following tests, this would allow me to fi= x > correctly the Tekram NVRAM sync. table: >=20 > 1) Use latest sym-1.6.1 driver (for 4.0 just steal driver files from > -current) > (You may patch it prior to do the tests, but it is not required) >=20 > 2) Edit sym_hipd.c and add the following 'define' at the beginning of > the source:=20 > #define=09SYM_CONF_DEBUG_NVRAM > (Or add -DSYM_CONF_DEBUG_NVRAM to the compilation options) >=20 > 3) Starting with 20 Mega-transfers per second until maximum possible, try > successivelly several sync. speeds (all values if only the 4 possible > discrete values are allowed) from the NVRAM and send me the driver boo= t > messages. If you have several SCSI devices, using different values for > each device can cover the sync. value range in a fiew runs. >=20 > Thanks in advance, >=20 > Regards, > Gerard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 13 9: 5:16 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from reticent.troll.no (reticent.troll.no [195.0.254.28]) by hub.freebsd.org (Postfix) with SMTP id 083B437B551 for ; Tue, 13 Jun 2000 09:05:10 -0700 (PDT) (envelope-from bhughes@trolltech.com) Received: (qmail 207 invoked by uid 1001); 13 Jun 2000 16:05:09 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 13 Jun 2000 16:05:09 -0000 Date: Tue, 13 Jun 2000 18:05:08 +0200 (CEST) From: "Bradley T. Hughes" X-Sender: bhughes@reticent.troll.no To: =?ISO-8859-1?Q?G=E9rard_Roudier?= Cc: freebsd-stable@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Problem with newer sym driver on a Tekram DC-390U2W controller In-Reply-To: Message-ID: 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 X-Loop: FreeBSD.org On Tue, 13 Jun 2000, G=E9rard Roudier wrote: >=20 > Hello, >=20 > Thanks for the report and sorry for the breakage. Unfortunately I haven't > any Tekram board and so, risk of device setup breakage is more likely to > happen for these boards due to their proprietary NVRAM layout. Tekram use > to speak highly of their success under notably Linux and seem to want to > provide their own drivers. May-be, for this reason, they never sent me an= y > of their SYM53C8XX based SCSI boards for driver testing. i tried tekram's drivers, but my machine would reboot itself randomly for some odd reason... the sym driver has proven much more stable > Well. I have an explanation of the breakage. The table used by the driver > to translate the NVRAM sync. tag to sync. factor is probably wrong. The > values seem to be rather ((sync. period)/4 in nano-seconds) than true SCS= I > sync. factors. >=20 > Here it the offending table: >=20 > static u_char Tekram_sync[16] =3D > =09{25,31,37,43, 50,62,75,125, 12,15,18,21, 6,7,9,10}; >=20 > The below preliminar patch should work-around the problem: >=20 > --- sym_hipd.c.0613=09Tue Jun 13 14:58:18 2000 > +++ sym_hipd.c=09Tue Jun 13 15:17:54 2000 > @@ -2960,11 +2960,15 @@ > =09=09sym_nvram_setup_target (np, i, nvram); > =20 > =09=09/* > -=09=09 * For now, guess PPR support from the period. > +=09=09 * For now, guess PPR/DT support from the period=20 > +=09=09 * and BUS width. > =09=09 */ > -=09=09if (tp->tinfo.user.period <=3D 9) { > -=09=09=09tp->tinfo.user.options |=3D PPR_OPT_DT; > -=09=09=09tp->tinfo.user.offset =3D np->maxoffs_dt; > +=09=09if (np->features & FE_ULTRA3) { > +=09=09=09if (tp->tinfo.user.period <=3D 9=09&& > +=09=09=09 tp->tinfo.user.width =3D=3D BUS_16_BIT) { > +=09=09=09=09tp->tinfo.user.options |=3D PPR_OPT_DT; > +=09=09=09=09tp->tinfo.user.offset =3D np->maxoffs_dt; > +=09=09=09} > =09=09} > =20 > =09=09if (!tp->usrtags) > ----------------------- Cut there ---------------------- after applying this to the 1.6.1 driver from -CURRENT, everything works great [snip] -- Bradley T. Hughes Waldemar Thranes gt. 98B N-0175 Oslo, Norway Office: +47 21 60 48 92 Mobile: +47 92 01 97 81 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 13 9:17:11 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.clarkson.edu (mail.clarkson.edu [128.153.4.10]) by hub.freebsd.org (Postfix) with SMTP id EC6A337BF19 for ; Tue, 13 Jun 2000 09:17:02 -0700 (PDT) (envelope-from cohentl@clarkson.edu) Received: (qmail 4159 invoked by uid 0); 13 Jun 2000 16:16:56 -0000 Received: from sirius.clarkson.edu (HELO sirius) (128.153.48.53) by mail.clarkson.edu with SMTP; 13 Jun 2000 16:16:56 -0000 Date: Tue, 13 Jun 2000 12:16:59 -0400 (EDT) From: Todd Cohen To: Grard Roudier Cc: freebsd-stable@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Problem with newer sym driver on a Tekram DC-390U2W controller In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Different but related question, are the DC-315U cards supported? On Tue, 13 Jun 2000, Bradley T. Hughes wrote: > On Tue, 13 Jun 2000, G=E9rard Roudier wrote: >=20 > >=20 > > Hello, > >=20 > > Thanks for the report and sorry for the breakage. Unfortunately I haven= 't > > any Tekram board and so, risk of device setup breakage is more likely t= o > > happen for these boards due to their proprietary NVRAM layout. Tekram u= se > > to speak highly of their success under notably Linux and seem to want t= o > > provide their own drivers. May-be, for this reason, they never sent me = any > > of their SYM53C8XX based SCSI boards for driver testing. >=20 > i tried tekram's drivers, but my machine would reboot itself randomly for > some odd reason... the sym driver has proven much more stable >=20 > > Well. I have an explanation of the breakage. The table used by the driv= er > > to translate the NVRAM sync. tag to sync. factor is probably wrong. The > > values seem to be rather ((sync. period)/4 in nano-seconds) than true S= CSI > > sync. factors. > >=20 > > Here it the offending table: > >=20 > > static u_char Tekram_sync[16] =3D > > =09{25,31,37,43, 50,62,75,125, 12,15,18,21, 6,7,9,10}; > >=20 > > The below preliminar patch should work-around the problem: > >=20 > > --- sym_hipd.c.0613=09Tue Jun 13 14:58:18 2000 > > +++ sym_hipd.c=09Tue Jun 13 15:17:54 2000 > > @@ -2960,11 +2960,15 @@ > > =09=09sym_nvram_setup_target (np, i, nvram); > > =20 > > =09=09/* > > -=09=09 * For now, guess PPR support from the period. > > +=09=09 * For now, guess PPR/DT support from the period=20 > > +=09=09 * and BUS width. > > =09=09 */ > > -=09=09if (tp->tinfo.user.period <=3D 9) { > > -=09=09=09tp->tinfo.user.options |=3D PPR_OPT_DT; > > -=09=09=09tp->tinfo.user.offset =3D np->maxoffs_dt; > > +=09=09if (np->features & FE_ULTRA3) { > > +=09=09=09if (tp->tinfo.user.period <=3D 9=09&& > > +=09=09=09 tp->tinfo.user.width =3D=3D BUS_16_BIT) { > > +=09=09=09=09tp->tinfo.user.options |=3D PPR_OPT_DT; > > +=09=09=09=09tp->tinfo.user.offset =3D np->maxoffs_dt; > > +=09=09=09} > > =09=09} > > =20 > > =09=09if (!tp->usrtags) > > ----------------------- Cut there ---------------------- >=20 > after applying this to the 1.6.1 driver from -CURRENT, everything works > great >=20 > [snip] >=20 > -- > Bradley T. Hughes > Waldemar Thranes gt. 98B N-0175 Oslo, Norway > Office: +47 21 60 48 92 > Mobile: +47 92 01 97 81 >=20 >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message >=20 --------------------------------------------------- http://www.clarkson.edu/~cohentl "Sometimes crazy things happen in circuits." - Muku, 1999 "The answers to lifes problems aren't at the bottom of bottles, they're on TV" - Homer J. Simpson --------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 13 9:47: 7 2000 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 B018237BF6B for ; Tue, 13 Jun 2000 09:47:00 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id KAA24987; Tue, 13 Jun 2000 10:46:23 -0600 (MDT) (envelope-from ken) Date: Tue, 13 Jun 2000 10:46:23 -0600 From: "Kenneth D. Merry" To: thomas.graichen@innominate.de Cc: Takefumi SAYO , tech@ioiscsi.com, scsi@FreeBSD.ORG Subject: Re: Initio INIC-941 PCI SCSI driver for FreeBSD 4.0-RELEASE Message-ID: <20000613104623.B24786@panzer.kdm.org> References: <20000611013840D.stake@po.shiojiri.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from graichen@innominate.de on Tue, Jun 13, 2000 at 08:49:48AM +0200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jun 13, 2000 at 08:49:48 +0200, Thomas Graichen wrote: > On Sun, 11 Jun 2000, Takefumi SAYO wrote: > > and > > > > (cd0:iha0:0:6:0): got CAM status 0xb > > (cd0:iha0:0:6:0): fatal error, failed to attach to device > > (cd0:iha0:0:6:0): lost device > > (cd0:iha0:0:6:0): removing device entry > > > > if no media presents in the removable device. > > > > Could you fix this if you have time? Because I don't know > > anything about SCSI and CAM. :-( > > > i don't know much more either :-) ... but i think you may ask this > on the scsi list (i'll cc this mail to it too) - maybe someone > there might help Status 0xb is a command timeout. It means the drive didn't respond to the READ CAPACITY command within 20 seconds. What kind of CDROM drive are you using? Does it do the same thing with other SCSI cards? Even though the cd(4) driver doesn't attach, the pass(4) driver should attach if you have it configured. Type 'camcontrol devlist' to see which pass(4) driver instance is attached to the drive, then you can do things like: (if the drive is attached as 'pass5') camcontrol inquiry pass5 camcontrol tur pass5 -v > maybe some more words about the initio driver: i currently have > absolutely no time to further work on this - so it would be > really fine if anyone might find the time to get this > going ... i may test it - i have both conteollers > here - one a100 and one 9100u ... Maybe someone will volunteer to work on it. 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 Tue Jun 13 9:47:58 2000 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 C074037BFD9; Tue, 13 Jun 2000 09:47:43 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id KAA24929; Tue, 13 Jun 2000 10:38:25 -0600 (MDT) (envelope-from ken) Date: Tue, 13 Jun 2000 10:38:25 -0600 From: "Kenneth D. Merry" To: Todd Cohen Cc: Grard Roudier , freebsd-stable@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Problem with newer sym driver on a Tekram DC-390U2W controller Message-ID: <20000613103825.A24786@panzer.kdm.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from cohentl@clarkson.edu on Tue, Jun 13, 2000 at 12:16:59PM -0400 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jun 13, 2000 at 12:16:59 -0400, Todd Cohen wrote: > Different but related question, are the DC-315U cards supported? If you use Tekram's driver, yes. Those cards, as well as their DC-395 series cards are based on Tekram's own S1040 chip. From the driver, though, it appears that the card doesn't have a SCSI phase engine, so there will be multiple interrupts per transaction. You would probably be beter off getting one of their Symbios/LSI based boards. 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 Tue Jun 13 10:30:53 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from front2m.grolier.fr (front2m.grolier.fr [195.36.216.52]) by hub.freebsd.org (Postfix) with ESMTP id D615537B649; Tue, 13 Jun 2000 10:30:34 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from ppp-108-3.villette.club-internet.fr (ppp-108-3.villette.club-internet.fr [194.158.108.3]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA10848; Tue, 13 Jun 2000 19:30:27 +0200 (MET DST) Date: Tue, 13 Jun 2000 19:07:18 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: "Bradley T. Hughes" Cc: freebsd-stable@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Problem with newer sym driver on a Tekram DC-390U2W controller In-Reply-To: Message-ID: 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 X-Loop: FreeBSD.org On Tue, 13 Jun 2000, Bradley T. Hughes wrote: > On Tue, 13 Jun 2000, G=E9rard Roudier wrote: >=20 > > Hello, > >=20 > > Thanks for the report and sorry for the breakage. Unfortunately I haven= 't > > any Tekram board and so, risk of device setup breakage is more likely t= o > > happen for these boards due to their proprietary NVRAM layout. Tekram u= se > > to speak highly of their success under notably Linux and seem to want t= o > > provide their own drivers. May-be, for this reason, they never sent me = any > > of their SYM53C8XX based SCSI boards for driver testing. >=20 > i tried tekram's drivers, but my machine would reboot itself randomly for > some odd reason... the sym driver has proven much more stable Tekram ncr drivers that are available in source form are driving the SYMBIOS chips in a very sub-optimal way. I don't know about binary-only drivers from Tekram, but my guess is that they may not be far better. I donnot want to know why some are highly broken, but even when they seem to work, using them when an alternate driver is available is probably not a good idea, in my opinion. For people using proprietary O/Ses and having Ultra-2 capable Tekram SYMBIOS based controllers, reflashing the BIOS with the SYMBIOS one can be tried, given that these boards seem to use SYMBIOS compatible implementation for NVRAM and FLASH memory. I cannot be 100% sure of this to work, but if it does, then drivers from SYMBIOS will probably accept to attach these boards. By the way, if I ever get a Tekram U2[B/W] controller, I will first try to SYMBIOSIFY it :-) prior to using it. You may try the above at your own risk (of making the board unusable if bad luck) or try to get a confirmation from Tekram prior to reflashing the board. ;-) > > Well. I have an explanation of the breakage. The table used by the driv= er > > to translate the NVRAM sync. tag to sync. factor is probably wrong. The > > values seem to be rather ((sync. period)/4 in nano-seconds) than true S= CSI > > sync. factors. > >=20 > > Here it the offending table: > >=20 > > static u_char Tekram_sync[16] =3D > > =09{25,31,37,43, 50,62,75,125, 12,15,18,21, 6,7,9,10}; > >=20 > > The below preliminar patch should work-around the problem: > >=20 > > --- sym_hipd.c.0613=09Tue Jun 13 14:58:18 2000 > > +++ sym_hipd.c=09Tue Jun 13 15:17:54 2000 > > @@ -2960,11 +2960,15 @@ > > =09=09sym_nvram_setup_target (np, i, nvram); > > =20 > > =09=09/* > > -=09=09 * For now, guess PPR support from the period. > > +=09=09 * For now, guess PPR/DT support from the period=20 > > +=09=09 * and BUS width. > > =09=09 */ > > -=09=09if (tp->tinfo.user.period <=3D 9) { > > -=09=09=09tp->tinfo.user.options |=3D PPR_OPT_DT; > > -=09=09=09tp->tinfo.user.offset =3D np->maxoffs_dt; > > +=09=09if (np->features & FE_ULTRA3) { > > +=09=09=09if (tp->tinfo.user.period <=3D 9=09&& > > +=09=09=09 tp->tinfo.user.width =3D=3D BUS_16_BIT) { > > +=09=09=09=09tp->tinfo.user.options |=3D PPR_OPT_DT; > > +=09=09=09=09tp->tinfo.user.offset =3D np->maxoffs_dt; > > +=09=09=09} > > =09=09} > > =20 > > =09=09if (!tp->usrtags) > > ----------------------- Cut there ---------------------- >=20 > after applying this to the 1.6.1 driver from -CURRENT, everything works > great Thanks for the quick reply. I have looked into their driver for FreeBSD-4.0. The sync. table hasn't changed since the time I stole it :) and their driver actually returns the values from the table as user settings to CAM. This is obviously wrong. I intend to commit the patch above for now and let `sym' be as wrong as=20 Tekram driver on this point, but not more. :-) Regards, Gerard. =20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 13 10:56: 3 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from front3m.grolier.fr (front3m.grolier.fr [195.36.216.53]) by hub.freebsd.org (Postfix) with ESMTP id 7A1F937BFD3; Tue, 13 Jun 2000 10:55:51 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from ppp-111-67.villette.club-internet.fr (ppp-111-67.villette.club-internet.fr [194.158.111.67]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA16209; Tue, 13 Jun 2000 19:55:42 +0200 (MET DST) Date: Tue, 13 Jun 2000 19:33:03 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: "Kenneth D. Merry" Cc: Todd Cohen , freebsd-stable@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Problem with newer sym driver on a Tekram DC-390U2W controller In-Reply-To: <20000613103825.A24786@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 13 Jun 2000, Kenneth D. Merry wrote: > On Tue, Jun 13, 2000 at 12:16:59 -0400, Todd Cohen wrote: > > Different but related question, are the DC-315U cards supported? > > If you use Tekram's driver, yes. > > Those cards, as well as their DC-395 series cards are based on Tekram's own > S1040 chip. > > >From the driver, though, it appears that the card doesn't have a SCSI phase > engine, so there will be multiple interrupts per transaction. And it appears that some non negligible amount of IOs through the PCI BUS is to be performed for each interrupt. When the BUS is busy, this may result in the CPU being stalled uselessly for micro-seconds (equivalent to thousands of instructions lost given modern CPUs). Under an O/S or a system that is either doing one thing at time or nothing most of the time, this probably does not make significant difference. But under a UNIX O/S, this probably is a significant penalty compared to SYMBIOS chips (given an appropriate software driver that takes advantage of SYMBIOS chips capabilities). Price difference between Tekram 3X5 and SCSI mode equivalent but PCI far superior Tekram 390-X controllers seems low-enough for me to claim that purchasing a 390-X is a far better buy. If we take into account the price of SCSI devices, then bying a 3X5 boards seems just stupid to me. > You would probably be beter off getting one of their Symbios/LSI based > boards. Indeed. Gerard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 13 21:23:57 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from fanying.fynet.com (fanying.fy-net.com [208.51.149.66]) by hub.freebsd.org (Postfix) with ESMTP id 4F7EA37B979 for ; Tue, 13 Jun 2000 21:23:54 -0700 (PDT) (envelope-from fanying@fynet.com) Received: from localhost (fanying@localhost) by fanying.fynet.com (8.9.3/8.9.3) with ESMTP id AAA03435 for ; Wed, 14 Jun 2000 00:25:04 -0400 Date: Wed, 14 Jun 2000 00:25:03 -0400 (EDT) From: Fanying Jen To: freebsd-scsi@freebsd.org Subject: Booting from a RAID with FreeBSD Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have seen Linux booting from a RAID device and there is even a HOWTO on configuring such a setup can this be done on FreeBSD? ------------------------------------------------------------------ Fanying Jen (Network Administrator) Email: fanying@fynet.com fanying@fy-net.com fanying@fanying.com fanying@fanying.fynet.com fanying@fanying.fy-net.com fanying@fanying.fanying.com Ham Radio: KC2FRL (Tech No-Code) Pgp Key: http://www.fynet.com/fanying/pgpkey.html Forsale: http://www.fynet.com/fanying/forsale.html The Fanying Jen Network http://www.fy-net.com/ http://www.fynet.com/ ------------------------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 13 21:28:57 2000 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 6E4C937C04F for ; Tue, 13 Jun 2000 21:28:53 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id WAA29989; Tue, 13 Jun 2000 22:28:31 -0600 (MDT) (envelope-from ken) Date: Tue, 13 Jun 2000 22:28:31 -0600 From: "Kenneth D. Merry" To: Fanying Jen Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Booting from a RAID with FreeBSD Message-ID: <20000613222831.A29959@panzer.kdm.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from fanying@fynet.com on Wed, Jun 14, 2000 at 12:25:03AM -0400 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Jun 14, 2000 at 00:25:03 -0400, Fanying Jen wrote: > I have seen Linux booting from a RAID device and there is even a HOWTO on > configuring such a setup can this be done on FreeBSD? You'll have to be more specific about what kind of RAID array it is. Is this a Mylex or AMI PCI RAID card, a SCSI-SCSI RAID controller, Vinum with RAID 5, or what? If it's a SCSI-SCSI RAID controller, it should look just like a hard disk to the OS, and you should be able to install FreeBSD on it without trouble. 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 Wed Jun 14 7: 1:27 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from niagara.shiojiri.ne.jp (niagara.shiojiri.ne.jp [203.141.192.49]) by hub.freebsd.org (Postfix) with ESMTP id BC45637C1B9 for ; Wed, 14 Jun 2000 07:01:22 -0700 (PDT) (envelope-from stake@po.shiojiri.ne.jp) Received: from localhost (ppp066.shiojiri.ne.jp [203.141.192.194]) by niagara.shiojiri.ne.jp (8.9.3/3.7W-:0052516) with ESMTP id XAA13395; Wed, 14 Jun 2000 23:00:40 +0900 (JST) References: <20000611013840D.stake@po.shiojiri.ne.jp> In-Reply-To: ; from graichen@innominate.de on Tue, Jun 13, 2000 at 08:49:48AM +0200 Subject: Re: Initio INIC-941 PCI SCSI driver for FreeBSD 4.0-RELEASE To: thomas.graichen@innominate.de Cc: Takefumi SAYO , tech@ioiscsi.com, scsi@FreeBSD.ORG X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) User-Agent: Mutt/1.2i Content-Disposition: inline Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000614225332T.stake@po.shiojiri.ne.jp> Date: Wed, 14 Jun 2000 22:53:32 +0900 From: Takefumi SAYO X-Dispatcher: imput version 20000228(IM140) Lines: 85 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org From: "Kenneth D. Merry" Subject: Re: Initio INIC-941 PCI SCSI driver for FreeBSD 4.0-RELEASE Date: Tue, 13 Jun 2000 10:46:23 -0600 > On Tue, Jun 13, 2000 at 08:49:48 +0200, Thomas Graichen wrote: > > On Sun, 11 Jun 2000, Takefumi SAYO wrote: > > > and > > > > > > (cd0:iha0:0:6:0): got CAM status 0xb > > > (cd0:iha0:0:6:0): fatal error, failed to attach to device > > > (cd0:iha0:0:6:0): lost device > > > (cd0:iha0:0:6:0): removing device entry > > > > > > if no media presents in the removable device. > > > > > > Could you fix this if you have time? Because I don't know > > > anything about SCSI and CAM. :-( > > > > > i don't know much more either :-) ... but i think you may ask this > > on the scsi list (i'll cc this mail to it too) - maybe someone > > there might help > > Status 0xb is a command timeout. It means the drive didn't respond to the > READ CAPACITY command within 20 seconds. When I used 'cdrecord' on FreeBSD 3.4-RELEASE with IOI's driver, cdrecord said ... timeout or something like that, and I could not burn CD-R. But on 2.2.8-RELEASE, there was no problem, I think. > What kind of CDROM drive are you using? a SCSI-2 CD-R drive producted by Matsushita. kernel says the followings when booting. cd0 at iha0 bus 0 target 6 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 15) cd0: cd present [328831 x 2048 byte records] (As I mentioned in the report to Graichen, 'got CAM status 0xb' is not displayed if media is present in drive.) > Does it do the same thing with > other SCSI cards? Sorry... I don't have any other SCSI card. I bought IOI's card, because I saw penguin ready logo on it and it was not so expensive. :-) And is is not fully daemon ready now ... X-< > Even though the cd(4) driver doesn't attach, the pass(4) driver should > attach if you have it configured. Type 'camcontrol devlist' to see which > pass(4) driver instance is attached to the drive, then you can do things > like: (if the drive is attached as 'pass5') > > camcontrol inquiry pass5 > camcontrol tur pass5 -v I tried. bash-2.04# camcontrol devlist at scbus0 target 6 lun 0 (pass0) bash-2.04# camcontrol tur pass0 -v Unit is not ready CAM status is 0x280 (insert some CD-ROM into drive) bash-2.04# camcontrol tur pass0 -v Unit is ready > > maybe some more words about the initio driver: i currently have > > absolutely no time to further work on this - so it would be > > really fine if anyone might find the time to get this > > going ... i may test it - i have both conteollers > > here - one a100 and one 9100u ... > > Maybe someone will volunteer to work on it. I read 'newbusified' diffs that Graichen sent to me, but I could not understand how to newbusify Initio's driver... If some experts work on it, I'll be happy. -- Takefumi SAYO To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 14 9:49:31 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (Postfix) with ESMTP id 6894E37C258 for ; Wed, 14 Jun 2000 09:49:27 -0700 (PDT) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.10.1/8.10.1) with ESMTP id e5EGnQR25506 for ; Wed, 14 Jun 2000 18:49:26 +0200 (MET DST) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.42.7]) by mail2.siemens.de (8.10.1/8.10.1) with ESMTP id e5EGnPA24605 for ; Wed, 14 Jun 2000 18:49:25 +0200 (MET DST) Received: (from localhost) by curry.mchp.siemens.de (8.10.1/8.10.1) id e5EGnPL92616 for freebsd-scsi@freebsd.org; Wed, 14 Jun 2000 18:49:25 +0200 (CEST) Date: Wed, 14 Jun 2000 18:49:25 +0200 From: Andre Albsmeier To: freebsd-scsi@freebsd.org Subject: Newer Adaptec BIOS solves boot problem Message-ID: <20000614184925.A37666@curry.mchp.siemens.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Not directly related to FreeBSD but people who experienced the boot problem described in kern/16803 can upgrade their Adaptec controller BIOS to the new version 2.57.2 and the boot failure will go away. The new BIOS can be found at ftp://ftp.adaptec.digisle.net/eprom_bios/2940uw_bios_v2572.exe and ftp://ftp.adaptec.digisle.net/eprom_bios/2940u2w_bios_v2572.exe -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 14 21:23:42 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from proxy.outblaze.com (proxy.outblaze.com [202.77.223.120]) by hub.freebsd.org (Postfix) with SMTP id A913537BA3C for ; Wed, 14 Jun 2000 21:23:38 -0700 (PDT) (envelope-from rossl@outblaze.com) Received: (qmail 5344 invoked from network); 15 Jun 2000 04:24:17 -0000 Received: from unknown (HELO outblaze.com) (202.77.181.223) by proxy.outblaze.com with SMTP; 15 Jun 2000 04:24:17 -0000 Message-ID: <39485A80.FD7AD487@outblaze.com> Date: Thu, 15 Jun 2000 12:24:34 +0800 From: Ross Law Organization: Outblaze X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Subject: Problem using HP DAT drive under FreeBSD 3.4 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, Our machine has a HP DAT drive built in. The drive is identified as sa0 during boot up: Waiting 5 seconds for SCSI devices to settle sa0 at ahc0 bus 0 target 3 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 10.000MB/s transfers (10.000MHz, offset 32) changing root device to da0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled da0: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) But 'mt -f /dev/nrsa0 status' gives "permission denied" for ordinary user and "device not configured" for root user. Any suggestions? -- Ross Law Technical Staff Outblaze Ltd. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 15 6:54: 1 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id D693137B886 for ; Thu, 15 Jun 2000 06:53:58 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id GAA01538; Thu, 15 Jun 2000 06:53:53 -0700 Date: Thu, 15 Jun 2000 06:53:53 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Ross Law Cc: scsi@freebsd.org Subject: Re: Problem using HP DAT drive under FreeBSD 3.4 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Try changing the /dev/nrsa0 permissions for the normal user and try loading a tape first othewise. On Thu, 15 Jun 2000, Ross Law wrote: > > Hello, > > Our machine has a HP DAT drive built in. The drive is identified as sa0 > during boot up: > > > Waiting 5 seconds for SCSI devices to settle > sa0 at ahc0 bus 0 target 3 lun 0 > sa0: Removable Sequential Access SCSI-2 device > sa0: 10.000MB/s transfers (10.000MHz, offset 32) > changing root device to da0s1a > da0 at ahc0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-3 device > da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing > Enabled > da0: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) > > > But 'mt -f /dev/nrsa0 status' gives "permission denied" for ordinary > user and "device not configured" for root user. Any suggestions? > > -- > Ross Law > Technical Staff > Outblaze Ltd. > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 15 9:32:36 2000 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 1899437B5E5 for ; Thu, 15 Jun 2000 09:32:30 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id KAA42990 for scsi@FreeBSD.ORG; Thu, 15 Jun 2000 10:32:28 -0600 (MDT) (envelope-from ken) Date: Thu, 15 Jun 2000 00:08:40 -0600 From: "Kenneth D. Merry" To: Takefumi SAYO Cc: thomas.graichen@innominate.de, tech@ioiscsi.com, scsi@FreeBSD.ORG Subject: Re: Initio INIC-941 PCI SCSI driver for FreeBSD 4.0-RELEASE Message-ID: <20000615000840.A39913@panzer.kdm.org> References: <20000611013840D.stake@po.shiojiri.ne.jp> <20000614225332T.stake@po.shiojiri.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000614225332T.stake@po.shiojiri.ne.jp>; from stake@niagara.shiojiri.ne.jp on Wed, Jun 14, 2000 at 10:53:32PM +0900 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Jun 14, 2000 at 22:53:32 +0900, Takefumi SAYO wrote: > From: "Kenneth D. Merry" > Subject: Re: Initio INIC-941 PCI SCSI driver for FreeBSD 4.0-RELEASE > Date: Tue, 13 Jun 2000 10:46:23 -0600 > > > On Tue, Jun 13, 2000 at 08:49:48 +0200, Thomas Graichen wrote: > > > On Sun, 11 Jun 2000, Takefumi SAYO wrote: > > > > and > > > > > > > > (cd0:iha0:0:6:0): got CAM status 0xb > > > > (cd0:iha0:0:6:0): fatal error, failed to attach to device > > > > (cd0:iha0:0:6:0): lost device > > > > (cd0:iha0:0:6:0): removing device entry > > > > > > > > if no media presents in the removable device. > > > > > > > > Could you fix this if you have time? Because I don't know > > > > anything about SCSI and CAM. :-( > > > > > > > i don't know much more either :-) ... but i think you may ask this > > > on the scsi list (i'll cc this mail to it too) - maybe someone > > > there might help > > > > Status 0xb is a command timeout. It means the drive didn't respond to the > > READ CAPACITY command within 20 seconds. > > When I used 'cdrecord' on FreeBSD 3.4-RELEASE with IOI's driver, > cdrecord said ... timeout or something like that, and I could not > burn CD-R. But on 2.2.8-RELEASE, there was no problem, I think. Okay, that's good to know -- it likely worked at one point. > > What kind of CDROM drive are you using? > > a SCSI-2 CD-R drive producted by Matsushita. > kernel says the followings when booting. > > cd0 at iha0 bus 0 target 6 lun 0 > cd0: Removable CD-ROM SCSI-2 device > cd0: 20.000MB/s transfers (20.000MHz, offset 15) > cd0: cd present [328831 x 2048 byte records] > > (As I mentioned in the report to Graichen, 'got CAM status 0xb' is > not displayed if media is present in drive.) Seems like a normal drive, I guess. Here's one thing you can try. In sys/cam/scsi/scsi_cd.c, in the cdstart() function, in the CD_STATE_PROBE case, you'll find the following function call: scsi_read_capacity(csio, /*retries*/1, cddone, MSG_SIMPLE_Q_TAG, rcap, SSD_FULL_SIZE, /*timeout*/20000); The default timeout is 20 seconds. Try increasing that value to say 300 seconds (i.e. 300000 milliseconds). See if your drive reports a reasonable status then. If it does, try decreasing the timeout until you find the place where it fails. Some drives take a long time to return a read capacity command when there is no media present. Until now, 20 seconds has been long enough to catch most of them, but it may be that the timeout is too short for your drive. If we can find a timeout that'll do the trick, and it isn't too long, we may be able to increase the default timeout in the driver. If you'd like a slightly faster way to test this out, without recompiling your kernel, you can try this: camcontrol cmd pass0 -v -t 300 -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" That will issue a SCSI READ CAPACITY command to pass0, with a timeout of 300 seconds. If there is no media in the drive, and the command hasn't timed out, you should get SCSI sense information like this: # camcontrol cmd cd0 -v -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" camcontrol: error sending command (pass2:ahc1:0:4:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (pass2:ahc1:0:4:0): NOT READY asc:3a,0 (pass2:ahc1:0:4:0): Medium not present If there is media in the drive, you should get output like this: # camcontrol cmd cd0 -v -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" 187384 2048 If the command times out, you should get some sort of CAM status back that would indicate a timeout (probably 0xb). Anyway, you can start with say 300 seconds, and then decrease the timeout gradually until you get a failure with a timeout instead of SCSI sense information. > > Does it do the same thing with > > other SCSI cards? > > Sorry... I don't have any other SCSI card. I bought IOI's card, because > I saw penguin ready logo on it and it was not so expensive. :-) > And is is not fully daemon ready now ... X-< Unfortunately, you may be right. If you can manage to borrow another kind of SCSI card, we might be able to eliminate the driver as a possible source of problems. > > Even though the cd(4) driver doesn't attach, the pass(4) driver should > > attach if you have it configured. Type 'camcontrol devlist' to see which > > pass(4) driver instance is attached to the drive, then you can do things > > like: (if the drive is attached as 'pass5') > > > > camcontrol inquiry pass5 > > camcontrol tur pass5 -v > > I tried. > > bash-2.04# camcontrol devlist > at scbus0 target 6 lun 0 (pass0) > bash-2.04# camcontrol tur pass0 -v > Unit is not ready > CAM status is 0x280 Now that is strange -- that indicates the following status: CAM_REQ_INPROG, /* CCB request is in progress */ CAM_AUTOSNS_VALID = 0x80, CAM_SIM_QUEUED = 0x200,/* SIM has this command in it's queue */ If the command is returned, it shouldn't have a status of "in progress". It should either have a status of CAM_REQ_CMP, or some sort of error and possibly include some SCSI sense data. > (insert some CD-ROM into drive) > > bash-2.04# camcontrol tur pass0 -v > Unit is ready That's the expected behavior of course. > > > maybe some more words about the initio driver: i currently have > > > absolutely no time to further work on this - so it would be > > > really fine if anyone might find the time to get this > > > going ... i may test it - i have both conteollers > > > here - one a100 and one 9100u ... > > > > Maybe someone will volunteer to work on it. > > I read 'newbusified' diffs that Graichen sent to me, but I could not > understand how to newbusify Initio's driver... > If some experts work on it, I'll be happy. The conversion to newbus will only remove the warning about using compatibility shims, it shouldn't have any effect on the problem you're having. 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 Thu Jun 15 16: 6:42 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from home.dragondata.com (home.dragondata.com [204.137.237.2]) by hub.freebsd.org (Postfix) with ESMTP id 69B7937BBC2 for ; Thu, 15 Jun 2000 16:06:23 -0700 (PDT) (envelope-from toasty@celery.dragondata.com) Received: from celery.dragondata.com (celery.dragondata.com [205.253.12.6]) by home.dragondata.com (8.9.2/8.9.2) with ESMTP id SAA25883 for ; Thu, 15 Jun 2000 18:06:16 -0500 (CDT) Received: (from toasty@localhost) by celery.dragondata.com (8.9.3/8.9.3) id SAA56932 for freebsd-scsi@freebsd.org; Thu, 15 Jun 2000 18:06:12 -0500 (CDT) (envelope-from toasty) From: Kevin Day Message-Id: <200006152306.SAA56932@celery.dragondata.com> Subject: Bus resets appearing on wrong scsi busses? To: freebsd-scsi@freebsd.org Date: Thu, 15 Jun 2000 18:06:12 -0500 (CDT) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've got a system with many(7) SCSI busses. One bus has nothing other than a tape drive and autoloader. When I eject the tape from drive, it executes correctly, but I get: # camcontrol eject 3:1:0 Unit stopped successfully, Media ejected (pass7:ahc1:0:0:0): SCB 0xd - timed out while idle, SEQADDR == 0xa ahc1: Issued Channel A Bus Reset. 1 SCBs aborted Which really makes no sense, considering I wasn't talking to that device: # camcontrol devlist *snip* at scbus3 target 0 lun 0 (pass7,ch0) at scbus3 target 1 lun 0 (sa0,pass8) *snip* Then, another random scsi bus (even on a different card) will reset: (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. Has anyone seen anything like this? dmesg follows: Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #7: Wed Jun 14 22:48:35 CDT 2000 root@sportscaster.sportsdiv.midwaygames.internal:/usr/src/sys/compile/SPORTSCASTER Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon (498.34-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x387fbff real memory = 536739840 (524160K bytes) avail memory = 518483968 (506332K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 Programming 24 pins in IOAPIC #1 IOAPIC #1 intpin 0 -> irq 2 IOAPIC #1 intpin 4 -> irq 20 IOAPIC #1 intpin 8 -> irq 21 IOAPIC #1 intpin 9 -> irq 22 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170020, at 0xfec00000 io1 (APIC): apic id: 3, version: 0x00178020, at 0xfc8d9000 Preloaded elf kernel "kernel" at 0xc0391000. Pentium Pro MTRR support enabled md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci4: on pcib1 pci4: at 0.0 pcib2: at device 2.0 on pci0 pci2: on pcib2 pcib3: at device 31.0 on pci2 pci3: on pcib3 pci3: (vendor=0x8086, dev=0x1161) at 0.0 ahc0: port 0xbc00-0xbcff mem 0xfc8da000-0xfc8dafff irq 2 at device 2.0 on pci3 ahc0: aic7896/97 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: port 0xbd00-0xbdff mem 0xfc8db000-0xfc8dbfff irq 2 at device 2.1 on pci3 ahc1: aic7896/97 Wide Channel B, SCSI Id=7, 16/255 SCBs ahc2: port 0xbe00-0xbeff mem 0xfc8de000-0xfc8defff irq 20 at device 3.0 on pci3 ahc2: aic7896/97 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc3: port 0xb000-0xb0ff mem 0xfc8df000-0xfc8dffff irq 20 at device 3.1 on pci3 ahc3: aic7896/97 Wide Channel B, SCSI Id=7, 16/255 SCBs sym0: <896> port 0xb400-0xb4ff mem 0xfc8e0000-0xfc8e1fff,0xfc8e8000-0xfc8e83ff irq 21 at device 9.0 on pci3 sym0: Symbios NVRAM, ID 7, Fast-40, LVD, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: handling phase mismatch from SCRIPTS. sym1: <896> port 0xb800-0xb8ff mem 0xfc8f0000-0xfc8f1fff,0xfc8f8000-0xfc8f83ff irq 22 at device 9.1 on pci3 sym1: Symbios NVRAM, ID 7, Fast-40, LVD, parity checking sym1: open drain IRQ line driver, using on-chip SRAM sym1: using LOAD/STORE-based firmware. sym1: handling phase mismatch from SCRIPTS. pcib4: at device 30.0 on pci0 pci1: on pcib4 fxp0: port 0xaf00-0xaf3f mem 0xfc600000-0xfc6fffff,0xfc7fc000-0xfc7fcfff irq 16 at device 8.0 on pci1 fxp0: Ethernet address 00:e0:81:10:cd:19 fxp0: supplying EUI64: 00:e0:81:ff:fe:10:cd:19 ti0: <3Com 3c985-SX Gigabit Ethernet> mem 0xfc7f8000-0xfc7fbfff irq 18 at device 10.0 on pci1 ti0: Ethernet address: 00:60:08:f5:d0:b0 ahc4: port 0xa800-0xa8ff mem 0xfc7ff000-0xfc7fffff irq 19 at device 11.0 on pci1 ahc4: aic7860 Single Channel A, SCSI Id=7, 3/255 SCBs isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 pci0: (vendor=0x8086, dev=0x2413) at 31.3 irq 17 fdc0: direction bit not set fdc0: cmd 3 failed at out byte 1 of 3 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: This ppc chipset does not support the extended I/O port range...no problem ppc0: at port 0x378-0x37b irq 7 on isa0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppi0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port plip0: on ppbus0 unknown0: on isa0 unknown: can't assign resources unknown1: at port 0-0xf,0x80-0x90,0x94-0x9f,0xc0-0xde drq 4 on isa0 unknown2: at port 0x40-0x43 irq 0 on isa0 unknown3: at port 0x70-0x71 irq 8 on isa0 unknown: can't assign resources unknown4: at port 0x61 on isa0 npxisa0: at port 0xf0-0xff irq 13 on isa0 unknown5: at port 0x4d0-0x4d1,0xcf8-0xcff,0x10-0x1f,0x24-0x2d,0x30-0x3d,0x50-0x53,0x72-0x77,0x91-0x93,0xa2-0xbe,0xdf,0x400-0x47f,0x540-0x54f,0x480-0x4bf,0x20,0x21,0x22 iomem 0x9e000-0x9ffff,0xcd800-0xdbfff on isa0 unknown6: at port 0x2e,0x2f on isa0 unknown7: at iomem 0xfff80000-0xffffffff,0xffb80000-0xffbfffff on isa0 unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown8: at port 0x200-0x207 on isa0 unknown9: at port 0x330-0x331 irq 5 on isa0 unknown10: on isa0 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 SMP: AP CPU #1 Launched! ata0-slave: identify retries exceeded acd0: CD-RW at ata0-master using PIO4 Waiting 15 seconds for SCSI devices to settle (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. sa0 at ahc1 bus 0 target 1 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 20.000MB/s transfers (10.000MHz, offset 15, 16bit) da2 at ahc0 bus 0 target 1 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da2: 47702MB (97693755 512 byte sectors: 255H 63S/T 6081C) da3 at ahc0 bus 0 target 2 lun 0 da3: Fixed Direct Access SCSI-2 device da3: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da3: 47702MB (97693755 512 byte sectors: 255H 63S/T 6081C) da5 at ahc0 bus 0 target 4 lun 0 da5: Fixed Direct Access SCSI-2 device da5: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da5: 47702MB (97693755 512 byte sectors: 255H 63S/T 6081C) da6 at ahc0 bus 0 target 5 lun 0 da6: Fixed Direct Access SCSI-2 device da6: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da6: 47702MB (97693755 512 byte sectors: 255H 63S/T 6081C) da4 at ahc0 bus 0 target 3 lun 0 da4: Fixed Direct Access SCSI-2 device da4: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da4: 47702MB (97693755 512 byte sectors: 255H 63S/T 6081C) da7 at ahc0 bus 0 target 6 lun 0 da7: Fixed Direct Access SCSI-2 device da7: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da7: 47702MB (97693755 512 byte sectors: 255H 63S/T 6081C) da0 at sym0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) ch0 at ahc1 bus 0 target 0 lun 0 ch0: Removable Changer SCSI-2 device ch0: 3.300MB/s transfers ch0: 7 slots, 1 drive, 1 picker, 0 portals Mounting root from ufs:/dev/da0s1a To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 15 22: 0:12 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from web1903.mail.yahoo.com (web1903.mail.yahoo.com [128.11.23.52]) by hub.freebsd.org (Postfix) with SMTP id A57A837BD04 for ; Thu, 15 Jun 2000 22:00:10 -0700 (PDT) (envelope-from p_k_nandan@yahoo.com) Received: (qmail 7959 invoked by uid 60001); 16 Jun 2000 05:00:10 -0000 Message-ID: <20000616050010.7958.qmail@web1903.mail.yahoo.com> Received: from [203.197.172.105] by web1903.mail.yahoo.com; Thu, 15 Jun 2000 22:00:10 PDT Date: Thu, 15 Jun 2000 22:00:10 -0700 (PDT) From: "NandaKumar P.K." Subject: Reset device and reset bus is not working To: freebsd-scsi@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I am testing the HBA driver for our RAID controller card for FreeBSD 3.4. When i send the XPT_RESET_DEV and XPT_RESET_BUS using the "camcontrol" system is just hanging. I am handling both of these requests in the driver and sends the response to the CAM layer. Is it necessary to complete these commands in the request function (_action ) itself ? Because when i sent the response CAM_REQ_CMP from the request it was O.K. But in the actual case i pass the request to the firmware and when the response is received from the firmware i complete the request. Thanks Regards, Nandan __________________________________________________ Do You Yahoo!? Send instant messages with Yahoo! Messenger. http://im.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 15 22:21:24 2000 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 F1DEC37B853 for ; Thu, 15 Jun 2000 22:21:19 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id XAA49079; Thu, 15 Jun 2000 23:21:17 -0600 (MDT) (envelope-from ken) Date: Thu, 15 Jun 2000 23:21:17 -0600 From: "Kenneth D. Merry" To: "NandaKumar P.K." Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Reset device and reset bus is not working Message-ID: <20000615232117.A49011@panzer.kdm.org> References: <20000616050010.7958.qmail@web1903.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000616050010.7958.qmail@web1903.mail.yahoo.com>; from p_k_nandan@yahoo.com on Thu, Jun 15, 2000 at 10:00:10PM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jun 15, 2000 at 22:00:10 -0700, NandaKumar P.K. wrote: > Hi, > > I am testing the HBA driver for our RAID controller > card for FreeBSD 3.4. When i send the XPT_RESET_DEV > and XPT_RESET_BUS using the "camcontrol" system is > just hanging. I am handling both of these requests in > the driver and sends the response to the CAM layer. > > Is it necessary to complete these commands in the > request function (_action ) itself ? Because when i > sent the response CAM_REQ_CMP from the request it was > O.K. But in the actual case i pass the request to the > firmware and when the response is received from the > firmware i complete the request. That bug was fixed in the RELENG_3 branch after 3.4 was released. You need at least rev 1.42.2.21 of src/sys/cam/cam_xpt.c and at least rev 1.9.2.7 of src/sbin/camcontrol/camcontrol.c to fix the problem. 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 Thu Jun 15 22:35:45 2000 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 663E137B809 for ; Thu, 15 Jun 2000 22:35:42 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id XAA49218; Thu, 15 Jun 2000 23:35:29 -0600 (MDT) (envelope-from ken) Date: Thu, 15 Jun 2000 23:35:29 -0600 From: "Kenneth D. Merry" To: Kevin Day Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Bus resets appearing on wrong scsi busses? Message-ID: <20000615233529.A49174@panzer.kdm.org> References: <200006152306.SAA56932@celery.dragondata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200006152306.SAA56932@celery.dragondata.com>; from toasty@dragondata.com on Thu, Jun 15, 2000 at 06:06:12PM -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jun 15, 2000 at 18:06:12 -0500, Kevin Day wrote: > > I've got a system with many(7) SCSI busses. One bus has nothing other than a > tape drive and autoloader. When I eject the tape from drive, it executes > correctly, but I get: > > # camcontrol eject 3:1:0 > Unit stopped successfully, Media ejected > (pass7:ahc1:0:0:0): SCB 0xd - timed out while idle, SEQADDR == 0xa > ahc1: Issued Channel A Bus Reset. 1 SCBs aborted > > Which really makes no sense, considering I wasn't talking to that device: > > # camcontrol devlist > *snip* > at scbus3 target 0 lun 0 (pass7,ch0) > at scbus3 target 1 lun 0 (sa0,pass8) > *snip* > > Then, another random scsi bus (even on a different card) will reset: > > (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. > > > Has anyone seen anything like this? dmesg follows: That does seem rather odd. What happens if you type: camcontrol inquiry 3:1:0 -v Also, did you happen to rescan the bus to get the tape drive to appear? Typically the pass device is the first to attach. How long after you attempt to eject the tape does the timed out while idle message appear? Were you doing any changer operations at the same time? Is the behavior consistent? Also, why are you using camcontrol to eject the tape instead of 'mt offline'? 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 Thu Jun 15 23:15:34 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from home.dragondata.com (home.dragondata.com [204.137.237.2]) by hub.freebsd.org (Postfix) with ESMTP id DB5C137BC45 for ; Thu, 15 Jun 2000 23:15:30 -0700 (PDT) (envelope-from toasty@celery.dragondata.com) Received: from celery.dragondata.com (celery.dragondata.com [205.253.12.6]) by home.dragondata.com (8.9.2/8.9.2) with ESMTP id BAA06871; Fri, 16 Jun 2000 01:15:19 -0500 (CDT) Received: (from toasty@localhost) by celery.dragondata.com (8.9.3/8.9.3) id BAA57754; Fri, 16 Jun 2000 01:15:14 -0500 (CDT) (envelope-from toasty) From: Kevin Day Message-Id: <200006160615.BAA57754@celery.dragondata.com> Subject: Re: Bus resets appearing on wrong scsi busses? To: ken@kdm.org (Kenneth D. Merry) Date: Fri, 16 Jun 2000 01:15:13 -0500 (CDT) Cc: toasty@dragondata.com (Kevin Day), freebsd-scsi@FreeBSD.ORG In-Reply-To: <20000615233529.A49174@panzer.kdm.org> from "Kenneth D. Merry" at Jun 15, 2000 11:35:29 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I've got a system with many(7) SCSI busses. One bus has nothing other than a > > tape drive and autoloader. When I eject the tape from drive, it executes > > correctly, but I get: > > > > # camcontrol eject 3:1:0 > > Unit stopped successfully, Media ejected > > (pass7:ahc1:0:0:0): SCB 0xd - timed out while idle, SEQADDR == 0xa > > ahc1: Issued Channel A Bus Reset. 1 SCBs aborted > > > > Which really makes no sense, considering I wasn't talking to that device: > > > > # camcontrol devlist > > *snip* > > at scbus3 target 0 lun 0 (pass7,ch0) > > at scbus3 target 1 lun 0 (sa0,pass8) > > *snip* > > > > Then, another random scsi bus (even on a different card) will reset: > > > > (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. > > > > > > Has anyone seen anything like this? dmesg follows: > > That does seem rather odd. > > What happens if you type: > > camcontrol inquiry 3:1:0 -v # camcontrol inquiry 3:1:0 -v pass8: Removable Sequential Access SCSI-2 device pass8: Serial Number 0060154037 pass8: 20.000MB/s transfers (10.000MHz, offset 15, 16bit) also: # camcontrol inquiry 3:0:0 -v pass7: Removable Changer SCSI-2 device pass7: Serial Number 38002141 pass7: 3.300MB/s transfers > > Also, did you happen to rescan the bus to get the tape drive to appear? > Typically the pass device is the first to attach. Nope. Both targets 0 and 1 are physically the same device, too, which makes the attach order even weirder. > How long after you attempt to eject the tape does the timed out while idle > message appear? About 5 seconds. Then a second or two after that, I get the weird "bus reset delivered". > > Were you doing any changer operations at the same time? Nope. > > Is the behavior consistent? Yes, except for which other bus gets reset. It seems to pick a random scbus and reset it. > > Also, why are you using camcontrol to eject the tape instead of 'mt offline'? I was trying to be consistant with the other camcontrol commands I plan on using to load/unload the tapes with the changer. (I'd rather pass my script a bus:target:lun alone, than a bus:target:lun AND device name.) -- Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 15 23:32:29 2000 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 4278237B9C9 for ; Thu, 15 Jun 2000 23:32:22 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id AAA49882; Fri, 16 Jun 2000 00:32:20 -0600 (MDT) (envelope-from ken) Date: Fri, 16 Jun 2000 00:32:20 -0600 From: "Kenneth D. Merry" To: Kevin Day Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Bus resets appearing on wrong scsi busses? Message-ID: <20000616003219.B49742@panzer.kdm.org> References: <20000615233529.A49174@panzer.kdm.org> <200006160615.BAA57754@celery.dragondata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200006160615.BAA57754@celery.dragondata.com>; from toasty@dragondata.com on Fri, Jun 16, 2000 at 01:15:13AM -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jun 16, 2000 at 01:15:13 -0500, Kevin Day wrote: > > > I've got a system with many(7) SCSI busses. One bus has nothing other than a > > > tape drive and autoloader. When I eject the tape from drive, it executes > > > correctly, but I get: > > > > > > # camcontrol eject 3:1:0 > > > Unit stopped successfully, Media ejected > > > (pass7:ahc1:0:0:0): SCB 0xd - timed out while idle, SEQADDR == 0xa > > > ahc1: Issued Channel A Bus Reset. 1 SCBs aborted > > > > > > Which really makes no sense, considering I wasn't talking to that device: > > > > > > # camcontrol devlist > > > *snip* > > > at scbus3 target 0 lun 0 (pass7,ch0) > > > at scbus3 target 1 lun 0 (sa0,pass8) > > > *snip* > > > > > > Then, another random scsi bus (even on a different card) will reset: > > > > > > (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. > > > > > > > > > Has anyone seen anything like this? dmesg follows: > > > > That does seem rather odd. > > > > What happens if you type: > > > > camcontrol inquiry 3:1:0 -v > > # camcontrol inquiry 3:1:0 -v > pass8: Removable Sequential Access SCSI-2 device > pass8: Serial Number 0060154037 > pass8: 20.000MB/s transfers (10.000MHz, offset 15, 16bit) > > also: > > # camcontrol inquiry 3:0:0 -v > pass7: Removable Changer SCSI-2 device > pass7: Serial Number 38002141 > pass7: 3.300MB/s transfers Looks fine, I guess the commands are getting to the correct device. > > Also, did you happen to rescan the bus to get the tape drive to appear? > > Typically the pass device is the first to attach. > > Nope. Both targets 0 and 1 are physically the same device, too, which makes > the attach order even weirder. Hmm, odd indeed. Or maybe not. I don't think the sa(4) driver does any I/O to the drive on attach, so I suppose it does make sense. > > How long after you attempt to eject the tape does the timed out while idle > > message appear? > > About 5 seconds. Then a second or two after that, I get the weird "bus reset > delivered". So that indicates that some command was timing out after 5 seconds, but it was a command to the changer.... The weird thing is, 'camcontrol eject' has a timeout of 120 seconds. So it must be some other command. > > Were you doing any changer operations at the same time? > > Nope. > > > > > Is the behavior consistent? > > Yes, except for which other bus gets reset. It seems to pick a random scbus > and reset it. Hmm, that is weird indeed. > > Also, why are you using camcontrol to eject the tape instead of 'mt offline'? > > I was trying to be consistant with the other camcontrol commands I plan on > using to load/unload the tapes with the changer. (I'd rather pass my script > a bus:target:lun alone, than a bus:target:lun AND device name.) Make sense in one respect, but why not use chio to do the changer operations? With camcontrol you'll have to manually compose all of the SCSI commands to move tapes from the bins to the tape drive. Well, here are two things to try: - manually specify a 120 second timeout for the eject command. e.g.: camcontrol eject 3:1:0 -t 120 -v That shouldn't make any difference, since 120 seconds is the timeout that camcontrol should be using, but it's worth a shot. - try ejecting the tape with mt instead of camcontrol. 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 Fri Jun 16 10:15:55 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from fanying.fynet.com (fanying.fy-net.com [208.51.149.66]) by hub.freebsd.org (Postfix) with ESMTP id 447B037C045 for ; Fri, 16 Jun 2000 10:15:49 -0700 (PDT) (envelope-from fanying@fynet.com) Received: from localhost (fanying@localhost) by fanying.fynet.com (8.9.3/8.9.3) with ESMTP id NAA04892 for ; Fri, 16 Jun 2000 13:17:41 -0400 Date: Fri, 16 Jun 2000 13:17:41 -0400 (EDT) From: Fanying Jen To: freebsd-scsi@freebsd.org Subject: Vinum Problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am trying to configure a simple 128mb mirror volume but I keep on getting this error and can't figure out why. I keep on getting this error: Can't create vinum0 /dev/da1e Invalid Arguement (22) or something to that effect. What does that mean and how can I solve. ------------------------------------------------------------------ Fanying Jen (Network Administrator) Email: fanying@fynet.com fanying@fy-net.com fanying@fanying.com fanying@fanying.fynet.com fanying@fanying.fy-net.com fanying@fanying.fanying.com Ham Radio: KC2FRL (Tech No-Code) Pgp Key: http://www.fynet.com/fanying/pgpkey.html Forsale: http://www.fynet.com/fanying/forsale.html The Fanying Jen Network http://www.fy-net.com/ http://www.fynet.com/ ------------------------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jun 17 1:52:38 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from niagara.shiojiri.ne.jp (niagara.shiojiri.ne.jp [203.141.192.49]) by hub.freebsd.org (Postfix) with ESMTP id C0EFF37B79D for ; Sat, 17 Jun 2000 01:52:28 -0700 (PDT) (envelope-from stake@po.shiojiri.ne.jp) Received: from localhost (ppp030.shiojiri.ne.jp [203.141.192.158]) by niagara.shiojiri.ne.jp (8.9.3/3.7W-:0052516) with ESMTP id RAA04028; Sat, 17 Jun 2000 17:51:44 +0900 (JST) To: ken@kdm.org Cc: stake@po.shiojiri.ne.jp, thomas.graichen@innominate.de, tech@ioiscsi.com, scsi@FreeBSD.ORG Subject: Re: Initio INIC-941 PCI SCSI driver for FreeBSD 4.0-RELEASE In-Reply-To: <20000615000840.A39913@panzer.kdm.org> References: <20000614225332T.stake@po.shiojiri.ne.jp> <20000615000840.A39913@panzer.kdm.org> X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Sat_Jun_17_17:43:53_2000_809)--" Content-Transfer-Encoding: 7bit Message-Id: <20000617174358N.stake@po.shiojiri.ne.jp> Date: Sat, 17 Jun 2000 17:43:58 +0900 From: Takefumi SAYO X-Dispatcher: imput version 20000228(IM140) Lines: 374 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ----Next_Part(Sat_Jun_17_17:43:53_2000_809)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Kenneth D. Merry" Subject: Re: Initio INIC-941 PCI SCSI driver for FreeBSD 4.0-RELEASE Date: Thu, 15 Jun 2000 00:08:40 -0600 > On Wed, Jun 14, 2000 at 22:53:32 +0900, Takefumi SAYO wrote: > > From: "Kenneth D. Merry" > > Subject: Re: Initio INIC-941 PCI SCSI driver for FreeBSD 4.0-RELEASE > > Date: Tue, 13 Jun 2000 10:46:23 -0600 > > > > > On Tue, Jun 13, 2000 at 08:49:48 +0200, Thomas Graichen wrote: > > > > On Sun, 11 Jun 2000, Takefumi SAYO wrote: > > > > > and > > > > > > > > > > (cd0:iha0:0:6:0): got CAM status 0xb > > > > > (cd0:iha0:0:6:0): fatal error, failed to attach to device > > > > > (cd0:iha0:0:6:0): lost device > > > > > (cd0:iha0:0:6:0): removing device entry > > > > > > > > > > if no media presents in the removable device. > > > > > > > > > > Could you fix this if you have time? Because I don't know > > > > > anything about SCSI and CAM. :-( > > > > > > > > > i don't know much more either :-) ... but i think you may ask this > > > > on the scsi list (i'll cc this mail to it too) - maybe someone > > > > there might help > > > > > > Status 0xb is a command timeout. It means the drive didn't respond to the > > > READ CAPACITY command within 20 seconds. > > > > When I used 'cdrecord' on FreeBSD 3.4-RELEASE with IOI's driver, > > cdrecord said ... timeout or something like that, and I could not > > burn CD-R. But on 2.2.8-RELEASE, there was no problem, I think. > > Okay, that's good to know -- it likely worked at one point. > > > > What kind of CDROM drive are you using? > > > > a SCSI-2 CD-R drive producted by Matsushita. > > kernel says the followings when booting. > > > > cd0 at iha0 bus 0 target 6 lun 0 > > cd0: Removable CD-ROM SCSI-2 device > > cd0: 20.000MB/s transfers (20.000MHz, offset 15) > > cd0: cd present [328831 x 2048 byte records] > > > > (As I mentioned in the report to Graichen, 'got CAM status 0xb' is > > not displayed if media is present in drive.) > > Seems like a normal drive, I guess. Here's one thing you can try. In > sys/cam/scsi/scsi_cd.c, in the cdstart() function, in the CD_STATE_PROBE > case, you'll find the following function call: > > scsi_read_capacity(csio, > /*retries*/1, > cddone, > MSG_SIMPLE_Q_TAG, > rcap, > SSD_FULL_SIZE, > /*timeout*/20000); > > The default timeout is 20 seconds. Try increasing that value to say 300 > seconds (i.e. 300000 milliseconds). > > See if your drive reports a reasonable status then. > > If it does, try decreasing the timeout until you find the place where it > fails. > > Some drives take a long time to return a read capacity command when there > is no media present. Until now, 20 seconds has been long enough to catch > most of them, but it may be that the timeout is too short for your drive. > > If we can find a timeout that'll do the trick, and it isn't too long, we > may be able to increase the default timeout in the driver. > > If you'd like a slightly faster way to test this out, without recompiling > your kernel, you can try this: > > camcontrol cmd pass0 -v -t 300 -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" > > That will issue a SCSI READ CAPACITY command to pass0, with a timeout of > 300 seconds. > > If there is no media in the drive, and the command hasn't timed out, you > should get SCSI sense information like this: > > # camcontrol cmd cd0 -v -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" > camcontrol: error sending command > (pass2:ahc1:0:4:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (pass2:ahc1:0:4:0): NOT READY asc:3a,0 > (pass2:ahc1:0:4:0): Medium not present I got different result. It still says CAM status is 0xb. # camcontrol cmd pass0 -v -t 300 -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" camcontrol: error sending command CAM status is 0xb > If there is media in the drive, you should get output like this: > > # camcontrol cmd cd0 -v -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" > 187384 2048 # camcontrol cmd pass0 -v -t 300 -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" 331334 2048 > If the command times out, you should get some sort of CAM status back that > would indicate a timeout (probably 0xb). > > Anyway, you can start with say 300 seconds, and then decrease the timeout > gradually until you get a failure with a timeout instead of SCSI sense > information. After trying to increase timeout value, I found the following things. (by turning on CAM_DEBUG and putting many printfs into driver source...) * Other SCSI errors (like parity error, buffer overrun, etc.) are mapped to CAM_CMD_TIMEOUT in i91u_done() in i91u.c. * 'got CAM status 0xb' does *NOT* mean timeout, but results from direction mismatch in tul_next_state() in i91utmp.c. * I don't know what direction is and why mismatch ocurrs, but kernel gets no CAM error if direction check is commented out. (bypassing direction check may cause another problem...) Is this right behavior of driver? cd0 at iha0 bus 0 target 6 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Further investigation is beyond my skill, so I send what I changed from 'iha-991210.tar.gz' with this mail for SCSI hackers who can fix this problem correctly and newbusify driver. (Please see attached diff and Graichen's web page http://www.innominate.org/~tgr/ for iha-991210.tar.gz) Ofcourse I can test the driver with Initio INIC-941 PCI SCSI adapter and Matsushita CD-R CW-7502. # I also desire that IOI developers work on it as user support. ;-) -- ----Next_Part(Sat_Jun_17_17:43:53_2000_809)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Description: iha-991210-20000617.diff Content-Disposition: attachment; filename="iha-991210-20000617.diff" diff -rN iha-991210/a100.c iha-20000617/a100.c 33c33 < #include --- > /* #include */ 46c46 < #include --- > /* #include */ 100c100 < #ifdef 0 --- > #if 0 113c113 < #ifdef 0 --- > #if 0 139c139 < #ifdef 0 --- > #if 0 154c154 < #ifdef 0 --- > #if 0 180c180,184 < DATA_SET (pcidevice_set,a100_device); --- > #ifdef COMPAT_PCI_DRIVER > COMPAT_PCI_DRIVER(ihb, a100_device); > #else > DATA_SET (pcidevice_set, a100_device); > #endif /* COMPAT_PCI_DRIVER */ 267c271 < #ifdef 0 --- > #if 0 502c506 < #ifdef 0 --- > #if 0 1012a1017,1058 > } else if (pScb->SCB_HaStat == HOST_DO_DU) { > > /* > ** Data overrun(underrun) > */ > ccb->ccb_h.status = CAM_DATA_RUN_ERR; > > } else if (pScb->SCB_HaStat == HOST_BUS_FREE) { > > /* > ** Bus free > */ > ccb->ccb_h.status = CAM_UNEXP_BUSFREE; > > } else if (pScb->SCB_HaStat == HOST_BAD_PHAS) { > > /* > ** Bad phase > */ > ccb->ccb_h.status = CAM_SEQUENCE_FAIL; > > } else if (pScb->SCB_HaStat == HOST_INV_CMD) { > > /* > ** Invalid command > */ > ccb->ccb_h.status = CAM_REQ_INVALID; > > } else if (pScb->SCB_HaStat == HOST_SCSI_RST) { > > /* > ** SCSI bus reset > */ > ccb->ccb_h.status = CAM_SCSI_BUS_RESET; > > } else if (pScb->SCB_HaStat == HOST_DEV_RST) { > > /* > ** SCSI device reset > */ > ccb->ccb_h.status = CAM_SCSI_BUS_RESET; /* XXX right? */ > 1053c1099 < #ifdef 0 --- > #if 0 1617c1663 < #ifdef 0 --- > #if 0 diff -rN iha-991210/i91u.c iha-20000617/i91u.c 30c30 < #ifdef KERNEL --- > #ifdef _KERNEL 39c39 < #endif /* KERNEL */ --- > #endif /* _KERNEL */ 45c45 < #include --- > /* #include */ 83c83 < #ifdef KERNEL --- > #ifdef _KERNEL 100c100 < #endif /* KERNEL */ --- > #endif /* _KERNEL */ 114a115,117 > #ifdef COMPAT_PCI_DRIVER > COMPAT_PCI_DRIVER(iha, i91u_device); > #else 116c119 < --- > #endif /* COMPAT_PCI_DRIVER */ 211a215,256 > } else if (pScb->SCB_HaStat == HOST_DO_DU) { > > /* > ** Data overrun(underrun) > */ > ccb->ccb_h.status = CAM_DATA_RUN_ERR; > > } else if (pScb->SCB_HaStat == HOST_BUS_FREE) { > > /* > ** Bus free > */ > ccb->ccb_h.status = CAM_UNEXP_BUSFREE; > > } else if (pScb->SCB_HaStat == HOST_BAD_PHAS) { > > /* > ** Bad phase > */ > ccb->ccb_h.status = CAM_SEQUENCE_FAIL; > > } else if (pScb->SCB_HaStat == HOST_INV_CMD) { > > /* > ** Invalid command > */ > ccb->ccb_h.status = CAM_REQ_INVALID; > > } else if (pScb->SCB_HaStat == HOST_SCSI_RST) { > > /* > ** SCSI bus reset > */ > ccb->ccb_h.status = CAM_SCSI_BUS_RESET; > > } else if (pScb->SCB_HaStat == HOST_DEV_RST) { > > /* > ** SCSI device reset > */ > ccb->ccb_h.status = CAM_SCSI_BUS_RESET; /* XXX right? */ > 354a400 > 683a730,731 > /* XXX commented out. This line causes > XXX "resource_list_alloc: resource entry is busy" 688c736 < --- > */ 815,818d862 < < < < diff -rN iha-991210/i91utmp.c iha-20000617/i91utmp.c 1562c1562,1566 < pScb->SCB_HaStat = HOST_DO_DU; --- > > /* XXX commented out to avoid CAM error */ > /* XXX when booting with NO media in CD-ROM. */ > /* XXX Is this right? */ > /* pScb->SCB_HaStat = HOST_DO_DU; */ 1736d1739 < 1981d1983 < diff -rN iha-991210/iha-sys_conf_files.diff iha-20000617/iha-sys_conf_files.diff 1,11c1,13 < --- /sys/conf/files.orig Sat Sep 11 17:46:07 1999 < +++ /sys/conf/files Fri Dec 10 08:04:07 1999 < @@ -95,6 +95,8 @@ < dev/ccd/ccd.c optional ccd device-driver < dev/isp/isp_freebsd.c optional isp device-driver < dev/isp/isp.c optional isp device-driver < +dev/iha/a100.c optional iha device-driver < +dev/iha/i91u.c optional iha device-driver < #dev/dpt/dpt_control.c optional dpt device-driver < dev/dpt/dpt_scsi.c optional dpt device-driver < dev/en/midway.c optional en device-driver --- > *** /sys/conf/files.orig Thu Mar 9 01:17:06 2000 > --- /sys/conf/files Sun Jun 11 00:16:15 2000 > *************** > *** 172,177 **** > --- 172,179 ---- > dev/ida/ida_disk.c optional ida > dev/ida/ida_eisa.c optional ida eisa > dev/ida/ida_pci.c optional ida pci > + dev/iha/i91u.c optional iha > + dev/iha/a100.c optional ihb > dev/isp/isp_freebsd.c optional isp > dev/isp/isp.c optional isp > dev/isp/isp_target.c optional isp ----Next_Part(Sat_Jun_17_17:43:53_2000_809)---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jun 17 4:22:36 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from obsidian.noc.dfn.de (obsidian.noc.dfn.de [193.174.247.193]) by hub.freebsd.org (Postfix) with ESMTP id 2EE3A37B52D for ; Sat, 17 Jun 2000 04:22:32 -0700 (PDT) (envelope-from schweikh@obsidian.noc.dfn.de) Received: (from schweikh@localhost) by obsidian.noc.dfn.de (8.9.3/8.9.3) id NAA29529 for freebsd-scsi@freebsd.org; Sat, 17 Jun 2000 13:22:30 +0200 (MET DST) Message-ID: <20000617132230.A29473@obsidian.noc.dfn.de> Date: Sat, 17 Jun 2000 13:22:30 +0200 From: Jens Schweikhardt To: freebsd-scsi@freebsd.org Subject: hangs during boot Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org hello, world\n About every other time I boot my system (3.4-stable) hangs even before the kernel gets its chance to take over the hardware, which is an ASUS P2L97-S mobo, ACPI Bios Version 1005, Adaptec AIC 7880 SCSI Bios v2.01, Intel Celeron CPU @ 333MHz. When things go well, the SCSI bios says << for SCSI Select(TM) Utility>>> SCSI ID 0: SEAGATE ST31200N HARD DISK 1 SCSI ID 2: PIONEER CD-ROM DR-U10X SCSI ID 3: YAMAHA CRW6416S SCSI ID 6: IBM DCAS-34330 HARD DISK 2 When things go wrong, one of these happens: - hang before "SCSI ID 0:" is displayed - hang before "SEAGATE ..." is displayed - doesn't find target 3 or 6 - when the kernel could be booted: "ahc0:A:0: unknown SCSI bus phase. Attempting to continue" (one or more of these lines) - not sure when I've seen this one: "time-out failure during inquiry SCSI command. Rescanning SCSI bus" I've triple checked termination - it's on the hostadapter and on ID 0, which is the last device on an 8-connector cable of 1.5m length. The device sequence along the cable is: host adapter, ID 2, ID 3, ID 6, ID 0. I've unplugged the PIONEER or YAMAHA, no change. After pressing the reset button (and sometimes repeating the procedure) the system boots successfully and works like a charm. The system is switched on externally via a switch in the wall plug, (not using the ATX power button). Do I have a crappy mobo/on-board SCSI? Or is one of the SCSI devices the culprit? Should I rearrange the bus? What else can I do to track this down? Here's the dmesg output Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.4-RELEASE #0: Wed Apr 26 20:03:46 CEST 2000 toor@hal9000.details.de:/usr/src/sys/compile/HAL9000 Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 334092273 Hz CPU: Celeron (334.09-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x660 Stepping = 0 Features=0x183f9ff real memory = 134217728 (131072K bytes) avail memory = 128118784 (125116K bytes) Pentium Pro MTRR support enabled Probing for devices on PCI bus 0: chip0: rev 0x03 on pci0.0.0 chip1: rev 0x03 on pci0.1.0 chip2: rev 0x01 on pci0.4.0 chip3: rev 0x01 on pci0.4.3 ahc0: rev 0x00 int a irq 10 on pci0.6.0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs bktr0: rev 0x02 int a irq 11 on pci0.12.0 bti2c0: iicbb0: on bti2c0 iicbus0: on iicbb0 master-only smbus0: on bti2c0 bktr0: Hauppauge Model 38104 B208 Hauppauge WinCast/TV, Philips PAL I tuner. Probing for devices on PCI bus 1: vga0: rev 0x10 int a irq 11 on pci1.0.0 Probing for PnP devices: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> ed0 at 0x280-0x29f irq 5 on isa ed0: address 00:00:b4:38:0f:6f, type NE2000 (16 bit) atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A ppc0 at 0x378 irq 7 flags 0x40 on isa ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold lpt0: on ppbus 0 lpt0: Interrupt-driven port fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface changing root device to da0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 1006MB (2061108 512 byte sectors: 64H 32S/T 1006C) cd0 at ahc0 bus 0 target 2 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Logical unit not ready, manual intervention required da1 at ahc0 bus 0 target 6 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 20.000MB/s transfers (20.000MHz, offset 15) da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) ed0: device timeout cmd XF86_SVGA pid 309 tried to use non-present SYSVSHM cd1 at ahc0 bus 0 target 3 lun 0 cd1: Removable CD-ROM SCSI-2 device cd1: 10.000MB/s transfers (10.000MHz, offset 15) cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jun 17 11: 6:23 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from fanying.fynet.com (fanying.fy-net.com [208.51.149.66]) by hub.freebsd.org (Postfix) with ESMTP id 4078737B6AF for ; Sat, 17 Jun 2000 11:06:18 -0700 (PDT) (envelope-from fanying@fynet.com) Received: from localhost (fanying@localhost) by fanying.fynet.com (8.9.3/8.9.3) with ESMTP id OAA05668 for ; Sat, 17 Jun 2000 14:08:27 -0400 Date: Sat, 17 Jun 2000 14:08:27 -0400 (EDT) From: Fanying Jen To: freebsd-scsi@freebsd.org Subject: Controller Timed on a Hard Disk Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I finally got vinum to work, it turned out to be a bad hard disk. However, once I took the bad disk offline, another disk begins to acted up. Here is the diagram of the scsi chain. cindy.fynet.com fanying.fynet.com [T] [T] / \ [AHA 2940UW]=== ===[AHA 2940UW] \ / --[WDE9100 (0)]--[WDE9100 (1)]-- The disk that is now acting up is WDE9100(1) and it is giving the error message below. I am wondering why is FreeBSD keep on hiccuping whereas Linux doesn't complain at all? Jun 8 17:13:25 oxygen /kernel: (da1:ahc0:0:1:0): SCB 0x4 - timed out in Data-out phase, SEQADDR == 0x115 Jun 8 17:13:25 oxygen /kernel: (da1:ahc0:0:1:0): SCB 0x4 - timed out in Data-out phase, SEQADDR == 0x115 Jun 8 17:13:42 oxygen /kernel: (da1:ahc0:0:1:0): BDR message in message buffer Jun 8 17:13:42 oxygen /kernel: (da1:ahc0:0:1:0): BDR message in message buffer Jun 8 17:13:42 oxygen /kernel: (da1:ahc0:0:1:0): SCB 0x4 - timed out in Data-out phase, SEQADDR == 0x115 Jun 8 17:13:42 oxygen /kernel: (da1:ahc0:0:1:0): SCB 0x4 - timed out in Data-out phase, SEQADDR == 0x115 Jun 8 17:13:42 oxygen /kernel: (da1:ahc0:0:1:0): no longer in timeout, status = 34b Jun 8 17:13:42 oxygen /kernel: (da1:ahc0:0:1:0): no longer in timeout, status = 34b bash-2.03# Jun 8 17:13:42 oxygen /kernel: ahc0: Issued Channel A Bus Reset. 2 SCBs aborted Jun 8 17:13:42 oxygen /kernel: ahc0: Issued Channel A Bus Reset. 2 SCBs aborted Thanks. ------------------------------------------------------------------ Fanying Jen (Network Administrator) Email: fanying@fynet.com fanying@fy-net.com fanying@fanying.com fanying@fanying.fynet.com fanying@fanying.fy-net.com fanying@fanying.fanying.com Ham Radio: KC2FRL (Tech No-Code) Pgp Key: http://www.fynet.com/fanying/pgpkey.html Forsale: http://www.fynet.com/fanying/forsale.html The Fanying Jen Network http://www.fy-net.com/ http://www.fynet.com/ ------------------------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jun 17 11:36:59 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id 8727337B6AF for ; Sat, 17 Jun 2000 11:36:57 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id LAA00910; Sat, 17 Jun 2000 11:41:37 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200006171841.LAA00910@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Fanying Jen Cc: freebsd-scsi@freebsd.org Subject: Re: Controller Timed on a Hard Disk In-reply-to: Your message of "Sat, 17 Jun 2000 14:08:27 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 17 Jun 2000 11:41:37 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I finally got vinum to work, it turned out to be a bad hard disk. However, > once I took the bad disk offline, another disk begins to acted up. Here is > the diagram of the scsi chain. > > cindy.fynet.com fanying.fynet.com > [T] [T] > / \ > [AHA 2940UW]=== ===[AHA 2940UW] > \ / > --[WDE9100 (0)]--[WDE9100 (1)]-- > > The disk that is now acting up is WDE9100(1) and it is giving the error > message below. I am wondering why is FreeBSD keep on hiccuping whereas > Linux doesn't complain at all? You don't say what you've set the IDs of the controllers to in this diagram. As a general rule, though, I think that what you're trying to do is probably not going to be possible (I see signs of "I can share this array between two machines" thinking above). As for why Linux doesn't detect that it's sent a command and then lost it - who knows? One more reason not to use it, I guess, since I certainly value my SCSI I/O commands. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jun 17 12: 3:38 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from relay01.chello.nl (smtp.chello.nl [212.83.68.144]) by hub.freebsd.org (Postfix) with ESMTP id 0A27C37B7A1; Sat, 17 Jun 2000 12:03:36 -0700 (PDT) (envelope-from wkb@chello.nl) Received: from chello.nl ([213.46.78.184]) by relay01.chello.nl (InterMail vK.4.02.00.00 201-232-116 license 2ee4e7c625482f2f2a1950a80f6c8d58) with ESMTP id <20000617190423.XLVU10636.relay01@chello.nl>; Sat, 17 Jun 2000 21:04:23 +0200 Received: (from wkb@localhost) by chello.nl (8.9.3/8.9.3) id VAA00305; Sat, 17 Jun 2000 21:03:32 +0200 (CEST) (envelope-from wkb) Date: Sat, 17 Jun 2000 21:03:32 +0200 From: Wilko Bulte To: Mike Smith Cc: Fanying Jen , freebsd-scsi@FreeBSD.ORG Subject: Re: Controller Timed on a Hard Disk Message-ID: <20000617210332.A239@freebie.wbnet> Reply-To: wc.bulte@chello.nl References: <200006171841.LAA00910@mass.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200006171841.LAA00910@mass.osd.bsdi.com>; from msmith@FreeBSD.ORG on Sat, Jun 17, 2000 at 11:41:37AM -0700 X-OS: FreeBSD 4.0-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Jun 17, 2000 at 11:41:37AM -0700, Mike Smith wrote: > > I finally got vinum to work, it turned out to be a bad hard disk. However, > > once I took the bad disk offline, another disk begins to acted up. Here is > > the diagram of the scsi chain. > > > > cindy.fynet.com fanying.fynet.com > > [T] [T] > > / \ > > [AHA 2940UW]=== ===[AHA 2940UW] > > \ / > > --[WDE9100 (0)]--[WDE9100 (1)]-- > > > > The disk that is now acting up is WDE9100(1) and it is giving the error > > message below. I am wondering why is FreeBSD keep on hiccuping whereas > > Linux doesn't complain at all? > > You don't say what you've set the IDs of the controllers to in this > diagram. As a general rule, though, I think that what you're trying to > do is probably not going to be possible (I see signs of "I can share this > array between two machines" thinking above). Assuming (e.g.) ID6 and 7 for the 2 Adaptecs it should work as far as SCSI goes. I don't like the use of SE SCSI for clustering-like setups but... If you have a RAID array that can present multiple LUNs / storagesets you can give each machine it's own storage to bang onto. You are of course right in saying that just hooking up 2 machines to the same disk is a no-no (maybe you can get away with giving each machine it's own part[ition] of the disk -- Wilko Bulte http://www.freebsd.org "Do, or do not. There is no try" wilko@freebsd.org http://www.nlfug.nl - Yoda - The Empire Strikes Back To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jun 17 15: 6:35 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 1BFBE37B709 for ; Sat, 17 Jun 2000 15:06:33 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id PAA09059 for ; Sat, 17 Jun 2000 15:06:29 -0700 Date: Sat, 17 Jun 2000 15:06:31 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: scsi@freebsd.org Subject: HEADS-UP: for Qlogic (SCSI, Fibre Channel) HBA users (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ repeated from -current ] By tonight a new version of this driver will be checked in that no longer supports most of the config options previously used. The most obvious effect of this change will be that firmware can no longer be compiled into the isp driver (no firmware compiled in has been the default for some time). Instead, a separate kernel module (ispfw) can be loaded by adding the line ispfw_load="YES" to your /boot/loader.conf options. There is no automatic mechanism for unloading this after the isp(4) driver configures, but manual unloading (or some rc script style thingie) can then reclaim the 350KBytes of memory the f/w occupies. If you don't want to use a loadable module, this can be staticly linked (as a pseudo-device- ispfw). As ever, with such changes, leading edge config, toolchain && kernel source with a clean merge/config/rebuild of the kernels you use are a must. Complaints to me. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message