From owner-freebsd-new-bus Tue Mar 7 10:15:56 2000 Delivered-To: freebsd-new-bus@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 4264037C114 for ; Tue, 7 Mar 2000 10:15:50 -0800 (PST) (envelope-from imp@harmony.village.org) 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 LAA59574 for ; Tue, 7 Mar 2000 11:15:46 -0700 (MST) (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 LAA95578 for ; Tue, 7 Mar 2000 11:15:34 -0700 (MST) Message-Id: <200003071815.LAA95578@harmony.village.org> To: new-bus@freebsd.org Subject: Interrupt context and newbus Date: Tue, 07 Mar 2000 11:15:34 -0700 From: Warner Losh Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG OK. I'm trying to track down a crash that I get sometimes (not always, but 80% of the time) when I remove/insert a pccard and the question of newbus and interrupt safety came up. The issue has come up twice now. Once when I was having Bruce review some safety changes to sio and now with my current bug. I have a CF card that has two slices on it. Slice 1 is DOS, slice 2 is FreeBSD. I insert the card, copy files to the FreeBSD slice and to the DOS slice (via mount both cases), unmount everything and pop the card out. I then use the card for its purpose (booting NetBSD on my Everex Freestyle A-10 Associate) and then find that I need to modify the card, so in it goes into my laptop (or test gig). When I mount the FreeBSD partition (well, the first one, which usually has been the FreeBSD one), I get a panic: l trap 12: page fault while in kernel mode fault virtual address = 0x28 fault code = supervisor read, page not present instruction pointer = 0x8:0xc018cfa6 stack pointer = 0x10:0xc626bbf8 frame pointer = 0x10:0xc626bc10 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1243 (mount) interrupt mask = none kernel: type 12 trap, code=0 Stopped at dscheck+0x62: movl 0xc(%eax),%esi db> trace dscheck(c1c8a308,0) at dscheck+0x62 diskstrategy(c1c8a308,c08b3800,200,c08ec600,c09b4000) at diskstrategy+0xad readdisklabel(c08b3800,c08ec600,c09410d4,c08b3980,c08e9c80) at readdisklabel+0x53 dsopen(c08e9c80,2000,0,c09410e4,c09410e8) at dsopen+0x258 diskopen(c08e9c80,3,2000,c5d4c560,c626bd48) at diskopen+0x10b spec_open(c626bd48,c626bd00,c025d1c9,c626bd48,c626bd6c) at spec_open+0xfd spec_vnoperate(c626bd48,c626bd6c,c0254a1d,c626bd48,44) at spec_vnoperate+0x15 ufs_vnoperatespec(c626bd48,44,c08eca00,c6296a20,c0980980) at ufs_vnoperatespec+0x15 ffs_mountfs(c6296a20,c08eca00,c5d4c560,c031c740,c08ecafa) at ffs_mountfs+0x1a5 ffs_mount(c08eca00,bfbfeff0,bfbfef3c,c626be94,c5d4c560) at ffs_mount+0x53c mount(c5d4c560,c626bf80,0,bfbfeff0,806c876) at mount+0x507 syscall(2f,2f,2f,806c876,bfbfeff0) at syscall+0x176 Xint0x80_syscall() at Xint0x80_syscall+0x26 So, I did some poking around. The dscheck+0x62 is most likely sp = &ssp->dss_slices[dkslice(bp->b_dev)]; ==> lp = sp->ds_label; if (ssp->dss_secmult == 1) { ssp is NULL in the traceback, so this is a good guess. How can ssp be NULL? Well, if diskstrategy passes it a NULL pointer. So I'm a bit sumped about how this can happen. The ad_attach function appears to always create the disk when it prints the probe line. The ad_detach runction appears to invalidate the disk and then destroy the disk devices. So I'm confused. All of this happens from an interrupt context, especially the delete. Could this be an interrupt safety issue with newbus? Or am I barking up the wrong tree? More generally, how safe is newbus from an interrupt context? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Sat Mar 11 2:43:21 2000 Delivered-To: freebsd-new-bus@freebsd.org Received: from smtp06.wxs.nl (smtp06.wxs.nl [195.121.6.58]) by hub.freebsd.org (Postfix) with ESMTP id 58D5137B5DB for ; Sat, 11 Mar 2000 02:43:04 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org ([195.121.196.201]) by smtp06.wxs.nl (Netscape Messaging Server 4.05) with ESMTP id FR973D02.1C8 for ; Sat, 11 Mar 2000 11:42:49 +0100 Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id LAA06161 for new-bus@freebsd.org; Sat, 11 Mar 2000 11:42:56 +0100 (CET) (envelope-from asmodai) Date: Sat, 11 Mar 2000 11:42:55 +0100 From: Jeroen Ruigrok/Asmodai To: new-bus@freebsd.org Subject: Abstraction API for drivers Message-ID: <20000311114255.T68308@daemon.ninth-circle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [Matthew, please feel free to correct me] Hi guys, after Matthew Dodd and me discussed some abstracting the access to the newbus functionality with Poul-Henning Kamp. Basically what phk said was that we were repeating lots of code in our PCI drivers. Matthew and me agreed on that aspect, but were concerned about making the abstraction PCI only. If such an API would be created, it should be a complete solution. Basically one of the things that will repeat itself a lot in PCI drivers is: static int xl_probe(dev) device_t dev; { struct xl_type *t; t = xl_devs; while(t->xl_name != NULL) { if ((pci_get_vendor(dev) == t->xl_vid) && (pci_get_device(dev) == t->xl_did)) { device_set_desc(dev, t->xl_name); return(0); } t++; } return(ENXIO); } In the probe case of a driver we will always have some sort of if statement like the above excellent xl driver example. We will always pci_get_[vendor|device](dev) and comparing it to the vendor/device id of the struct array of devices. After we find matches, we will always want to set the name with device_set_desc(dev, name). In the case for PCI devices this will create a very repeatable piece of code all along the drivers. Of course, given the total different way how, for example, ISA, EISA, S-BUS, and such work this might provide some difficulty creating a sufficient general API to allow for bus-independant abstraction. And creating functionwrappers just for bus specific cases might be the only solution, but if we can avoid it, it would be cool. =) Ideas, comments, suggestions? Also, Matthew explained he had some issues with rman (resource manager), but I'll let him explain that... -- Jeroen Ruigrok vd Werven/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project There is no greater sorrow than to recall, in misery, the time when we were happy... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Sat Mar 11 9:24:13 2000 Delivered-To: freebsd-new-bus@freebsd.org Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by hub.freebsd.org (Postfix) with ESMTP id 7579B37BC99 for ; Sat, 11 Mar 2000 09:23:58 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 12TpcK-0001Kc-0A; Sat, 11 Mar 2000 17:23:56 +0000 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id RAA30462; Sat, 11 Mar 2000 17:30:31 GMT (envelope-from dfr@nlsystems.com) Date: Sat, 11 Mar 2000 17:26:06 +0000 (GMT) From: Doug Rabson To: Jeroen Ruigrok/Asmodai Cc: new-bus@freebsd.org Subject: Re: Abstraction API for drivers In-Reply-To: <20000311114255.T68308@daemon.ninth-circle.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 11 Mar 2000, Jeroen Ruigrok/Asmodai wrote: > [Matthew, please feel free to correct me] > > Hi guys, > > after Matthew Dodd and me discussed some abstracting the access to the > newbus functionality with Poul-Henning Kamp. > > Basically what phk said was that we were repeating lots of code in our > PCI drivers. Matthew and me agreed on that aspect, but were concerned > about making the abstraction PCI only. If such an API would be created, > it should be a complete solution. > > Basically one of the things that will repeat itself a lot in PCI drivers > is: > > static int xl_probe(dev) > device_t dev; > { > struct xl_type *t; > > t = xl_devs; > > while(t->xl_name != NULL) { > if ((pci_get_vendor(dev) == t->xl_vid) && > (pci_get_device(dev) == t->xl_did)) { > device_set_desc(dev, t->xl_name); > return(0); > } > t++; > } > > return(ENXIO); > } > > In the probe case of a driver we will always have some sort of if > statement like the above excellent xl driver example. > > We will always pci_get_[vendor|device](dev) and comparing it to the > vendor/device id of the struct array of devices. > > After we find matches, we will always want to set the name with > device_set_desc(dev, name). > > In the case for PCI devices this will create a very repeatable piece of > code all along the drivers. > > Of course, given the total different way how, for example, ISA, EISA, > S-BUS, and such work this might provide some difficulty creating a > sufficient general API to allow for bus-independant abstraction. And > creating functionwrappers just for bus specific cases might be the only > solution, but if we can avoid it, it would be cool. =) > > Ideas, comments, suggestions? I was discussing this with Nick Hibma a while ago. I intend to improve this situation for the next generation of newbus. What I'm intending is to write a general system for PnP matching. The driver would register a table of PnP IDs and optional descriptions, possibly something like: struct pnp_match ids[] = { {"eisa:PNP0500", "Standard PC COM port"}, {"eisa:PNP0501", "16550A-compatible COM port"}, ... {0, 0} }; Drivers would call a generic PnP matching routine which would allow 'plugins' to match specific kinds of PnP ID, e.g. eisa, pci, usb etc. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Sat Mar 11 12: 8: 3 2000 Delivered-To: freebsd-new-bus@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 98B2337BCEB for ; Sat, 11 Mar 2000 12:07:58 -0800 (PST) (envelope-from imp@harmony.village.org) 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 NAA78973; Sat, 11 Mar 2000 13:07:56 -0700 (MST) (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 NAA27217; Sat, 11 Mar 2000 13:07:31 -0700 (MST) Message-Id: <200003112007.NAA27217@harmony.village.org> To: Doug Rabson Subject: Re: Abstraction API for drivers Cc: Jeroen Ruigrok/Asmodai , new-bus@FreeBSD.ORG In-reply-to: Your message of "Sat, 11 Mar 2000 17:26:06 GMT." References: Date: Sat, 11 Mar 2000 13:07:31 -0700 From: Warner Losh Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Doug Rabson writes: : Drivers would call a generic PnP matching routine which would allow : 'plugins' to match specific kinds of PnP ID, e.g. eisa, pci, usb etc. pccard, cardbus should be added to the list. PCCARD and Cardbus is a more complex example. In pccard devices, there's an area of ram called this cis. The cis has a number of different things in it that can be used to identify a card. There are the familiar manufacturer and model strings, but also there's a manufacturer numeric ID (assigned by the pcmcia consortium), a numeric model number (assigned by the manufacturer), a notion of a function type (similar, but more restricted than, the pci device class) as well as some other card/function specific information needed by the driver (the ethernet address springs to mind for nic cards). I'm not sure how you'd encapsulate all this into a generic mechanism. Some drivers will match to a functional type of card (eg sio will match all modem/serial cards). Some drivers will want to match against the numeric IDs. Some will match against CIS strings. Some (the ed driver) will likely need to match against all of these things since some of the supported cards have CIS but no numeric ids, etc. I'm not sure how a generic scheme would fit into this morass of conflicting standards. Maybe each PnP bus needs to have a bus function that would take void * and match against the values, if present, for that card. bus_match_pnp_id(device_t bus, device_t child, int type, void *value) where type is an enum (or string) of some sort (likely string would be better for binary compatibility over the long haul). You could then write bus generic routines to do the matching based on the different types of information available. The bus' specific matching routine(s) should use the bus_match_pnp_id interface. What makes this messy is that you don't have a single ID that says yes or not, but rather a collection of them to match. It would be hard to come up with a good syntax for "smashing" the multiple ones into a single ID for pccard. For the numberic fields, this is easy (put mfg part in one word, and model part in the other word and use the agregate). For strings in PCCARD land, this is hard because the string can and does often contain any character at all. A quick survey shows that they match the following regular expression: [-A-Za-z0-9/.()+*]+ so you'd have to take the chance that there'd be no oddballs of a certain type like one of `~|\ and then use that as a separator. I think that I've seen ':' be used in CIS strings, but there are no entries in pccard.conf.sample right now that use it. Will have to look in the standard. Maybe the right thing to do is just use the numeric ones for pccard/cardbus and let those drivers that need to fall back to CIS matching to do so with a mechanism outside of this. The CIS strings aren't PnP identifiers after all, but are being abused as such with the current system. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message