From owner-freebsd-current Thu Dec 14 12:48:51 2000 From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 12:48:49 2000 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 5FD6237B400; Thu, 14 Dec 2000 12:48:49 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eBEKmcE84534; Thu, 14 Dec 2000 12:48:38 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.0) id eBEKlp140726; Thu, 14 Dec 2000 12:47:51 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Thu, 14 Dec 2000 12:47:51 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: current@FreeBSD.org Subject: Cardbus woes Cc: imp@FreeBSD.org, jon@FreeBSD.org Sender: jhb@foo.osd.bsdi.com Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG With the recent slaughter^Wrework of the PCI code, my hack to allocate resources for unattached PCI devices in pci_probe_nomatch() no longer works. The updated patch can be found at http://www.FreeBSD.org/~jhb/patches/cardbus.hack.patch. Since the PCI changes, inserting the cardbus card I have (Linksys 10/100 PCMPC200) will lock the kernel up hard. I've traced it down to the memcpy() in cardbus_read_tuple_mem() for the tuple containing the product info. If I pop the card out, then that interrupt manages to trigger something so that the machine unlocks, and continues. However, it seems the memcpy() only grabbed part of the info. Notably, the manufacturer string is just "Lin", rather than the full name (Linksys). dc0 fails to attach (the card is out now :-P) but the kernel continues to run fine. So, my Inspiron is backing to being totally dead on cardbus until the resource allocation is fixed. (or my patch is fixed if it is broken). In other news, while wandering through the cardbus code, I discovered that pccbb softc's have an internal mutex much to my surprise, and that they weren't quite being used properly AFAICT. In the pccb0 kthread, they were acquired/released without Giant. However, in the rest of the pccbb driver, they are acquired/released with Giant. This leads to lock order violations which could potentially deadlock the machine at some point. Also, the pccbb0 kthread holds the mutex across the entire card insertion and removal events, which is not quite right. Mutexes should only be held for short periods of time. As such, I've futzed around with the mutex operations in the pccbb driver some. It may not be completely correct, but I think it is an improvement. The patch for this can be found at http://www.FreeBSD.org/~jhb/patches/pccbb.patch. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message