From owner-freebsd-mobile Wed Aug 23 17: 8:19 2000 Delivered-To: freebsd-mobile@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id CE45C37B688 for ; Wed, 23 Aug 2000 17:08:14 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id SAA67824; Wed, 23 Aug 2000 18:08:13 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id SAA53460; Wed, 23 Aug 2000 18:08:00 -0600 (MDT) Message-Id: <200008240008.SAA53460@harmony.village.org> To: "Greg Smith" Subject: Re: PCMCIA ATA HD's under FreeeBSD 4.1R Cc: freebsd-mobile@FreeBSD.ORG In-reply-to: Your message of "Wed, 23 Aug 2000 17:34:57 GMT." References: Date: Wed, 23 Aug 2000 18:08:00 -0600 From: Warner Losh Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message "Greg Smith" writes: : 2) I can power down (pccardc power 1 0) this drive without unmounting. : unmounting afterwards causes panic fatal trap 12 (supervisor read, page not : found) Don't do that. :-) It currently isn't supported. It should be, but not in the way you think. When the drive goes away, it is gone and the umounting shouldn't cause a panic, but should issue a warning that the underlying device is gon. : Number 1 is an inconvenience, and it would be nice to alter some settings : somewhere to speed up the process since the machine seems to be locked up : during the interval. The problem is that some ata devices lie and say there are two devices when in fact there's only one. Soren tried to fix this, but there were some problems he ran into and backed it out. : Number 2, however, has me a little worried. This : suggests that pccardc/d do not interact with the file system. That would : imply that any uncommitted writes would not be flushed to the drive before : the drive is powered down. [Please excuse my ignorance if Unix does not : have the concept of delayed writes.] Generally speaking, pccard shouldn't interact with the file system. It shouldn't sneak its tendrils into that if it can be avoided. The basic problem is that there's no way of knowing if you've reinserted the same disk, or disk that is similar. If you've inserted the same disk, then it should flush. If you haven't, then it shouldn't. The disk subsystem has no way of knowing, for sure, which is which. ata should refuse to write, in a manner similar to CAM, the disk blocks when the drive goes away. CAM has an advantage over the ata pccard stuff. The SCSI drives do have serial numbers. ata flash don't appear to, and in any event it doesn't look like hot plug concents are in the ata drivers (I could be wrong, but that's what it appears). I've not looked into this problem since I'm not the ata driver maintainer and I've been focused on NEWCARD. : 9:47:11 ata2-slave: ata_command: timeout waiting for intr : 9:47:11 ata2-slave: identify failed This is where the controller is lying to the OS, or there's an OS bug. Soren thinks that the device is lying to the driver. He's suggested a flag that says "don't probe slave" or "don't probe master" despite what the device claims. He may be right in our needing this. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message