Date: Wed, 28 Jun 2000 16:51:38 -0600 From: Warner Losh <imp@village.org> To: mobile@freebsd.org Subject: Patch for the Nth insert of ata cards Message-ID: <200006282251.QAA59305@harmony.village.org>
next in thread | raw e-mail | index | archive | help
Here's a patch for the problems that people have been seeing when they insert a PCCARD or CF ata card, muck with it, eject it, and insert it again. Sometimes mucking with it again would result in a panic. This patch is against -stable. I'll port this to -current shortly. I'd like to thank Timing Solutions for giving me the 3 days of uninterrupted time to track this down. Warner http://people.freebsd.org/~imp/ata-insert-stable Log: End two weeks of on and off debugging. Fix the crash on the Nth insertion of a CF card, for random values of N > 1. With these fixes, I've been able to do 100 insert/remove of the cards w/o a crash with lots of system activity going on that in the past would help trigger the crash. The problem: FreeBSD creates dev_t's on the fly as they are needed and never destroys them. These dev_t's point to a struct disk that is used for housekeeping on the disk. When a device goes away, the struct disk pointer becomes a dangling pointer. Sometimes when the device comes back, the pointer will point to the new struct disk (in which case the insertion will work). Other times it won't (especially if any length of time has passed, since it is dependent on memory returned from malloc). The Fix: There is one of these dev_t's that is always correct. The device for the WHOLE_DISK_SLICE is always right. It gets set at create_disk() time. So, the fix is to spend a little CPU time and lookup the WHOLE_DISK_SLICE dev_t and use the si_disk from that in preference to the one that's in the device asking to do the I/O. In addition, we change the test of si_disk == NULL meaning that the dev needed to inherit properties from the pdev to dev->si_disk != pdev->si_disk. This test is a little stronger than the previous test, but can sometimes be fooled into not inheriting. However, the results of this fooling are that the old values will be used, which will generally always be the same as before. si_drv[12] are the only values that are copied that might pose a problem. They tend to change as the si_disk field would change, so it is a hole, but it is a small hole. One could correctly argue that one should replace much of this code with something much much better. I would be on the pro side of that argument. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006282251.QAA59305>