From edward.pilatowicz at sun.com Wed May 7 10:53:58 2008 From: edward.pilatowicz at sun.com (Edward Pilatowicz) Date: Wed, 7 May 2008 10:53:58 -0700 Subject: [amd-platform-discuss] problems with creating IBS provider package In-Reply-To: <20080423122241.GA6777@escobedo.amd.com> References: <20080423122241.GA6777@escobedo.amd.com> Message-ID: <20080507175358.GK213278@eng.sun.com> [ i'm not on this alias so be sure to cc me directly on replies ] hey hans, eric forwarded me your email. what you need to do is provide a devfsadm link generator plugin. this plugin will go into: /usr/lib/devfsadm/linkmod/ you can base your link generator off the source for other dtrace link generators: usr/src/cmd/devfsadm/dtrace_link.c the way this works, is that when the ibs driver calls ddi_create_minor_node(), that will generate a sysevent, which will result in devfsadm being run. devfsadm will then load all it's link generator plugins in an attempt to find one to handle the minor node event. you're plugin should then get run it will generate the necessary /dev/dtrace/provider/ link. then when dtrace is run later on and it scans /dev/dtrace for providers it will access this link there by loading and attaching the ibs provider driver. ed On Wed, Apr 23, 2008 at 02:22:41PM +0200, Hans Rosenfeld wrote: > I'm currently having some problems creating a SysV package for the IBS > provider. The package contains just the ibs modules and configuration > file, and some postinstall/preremove scripts to add/remove the driver > with add_drv and rem_drv. After installation of the package, the > provider sometimes works and sometimes it doesn't, and it never worked > after a system reboot. DTrace just keeps telling me that it can't find > matching probes. > > I don't quite understand why it worked occasionally, but I think the > problem is a missing symbolic link in /dev/dtrace/provider. The provider > works once I create this link by hand. IIUC this link is normally > created by devfsadm, I've seen that there are IBS-related changes to the > devfsadm code to do that. > > I think I'm missing something important here. I doubt I can just include > a new devfsadm in the IBS package, but creating the link with just ln in > the postinstall script doesn't seem right neither. Can anyone tell me > whats the right thing to do here? > > > Hans > > > -- > %SYSTEM-F-ANARCHISM, The operating system has been overthrown > > _______________________________________________ > amd-platform-discuss mailing list > amd-platform-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/amd-platform-discuss From hans.rosenfeld at amd.com Thu May 8 03:10:10 2008 From: hans.rosenfeld at amd.com (Hans Rosenfeld) Date: Thu, 8 May 2008 12:10:10 +0200 Subject: [amd-platform-discuss] problems with creating IBS provider package In-Reply-To: <20080507175358.GK213278@eng.sun.com> References: <20080423122241.GA6777@escobedo.amd.com> <20080507175358.GK213278@eng.sun.com> Message-ID: <20080508101010.GC12654@escobedo.amd.com> On Wed, May 07, 2008 at 10:53:58AM -0700, Edward Pilatowicz wrote: > eric forwarded me your email. what you need to do is provide a devfsadm > link generator plugin. this plugin will go into: > /usr/lib/devfsadm/linkmod/ > > you can base your link generator off the source for other dtrace > link generators: > usr/src/cmd/devfsadm/dtrace_link.c Thanks for that information. This is actually what I did after I figured out that devfsadm uses plugins to create the links. It's good to know that this was indeed the right way to do it. Hans -- %SYSTEM-F-ANARCHISM, The operating system has been overthrown From hans.rosenfeld at amd.com Thu May 29 10:51:45 2008 From: hans.rosenfeld at amd.com (Hans Rosenfeld) Date: Thu, 29 May 2008 19:51:45 +0200 Subject: [amd-platform-discuss] Questions regarding IBS attach function Message-ID: <20080529175145.GA8817@escobedo.amd.com> Hi, while trying to understand the IBS provider in detail, I stumbled upon this code in the attach routine: uint64_t val; val = rdmsr(0xc001001f); val = val | 0x400000000000; wrmsr(0xc001001f, val); drv_usecwait(10); pci_putl(0, 0x18, 3, 0x1cc, 0x100); drv_usecwait(10); This code enables PCI extended config space accesses through I/O registers 0xcf8/0xcfc and then sets up the IBS control register on the northbridge of node 0 to use LVT offset 0. The pci_putl() function is private to the IBS module. According to the BKDG, this setup of the IBS control register should already have been done by the BIOS, but if the driver assumes that it probably is not, it should do it on _all_ nodes, not just node 0. To fix this, the code would need to iterate over all nodes. Is there some public interface to get the node count, or would I have to read it either from the Node ID register, as in i86pc/os/mp_startup.c, or from lgrp_lpat_node_cnt from sys/memnode.h? Another problem I see here is the use of LVT offset 0, which is usually used by the machine check architecture. I couldn't find an interface to coordinate usage of the 4 possible LVT offsets. Maybe a nexus device claiming function 3 of the northbridges, as suggested by a comment in i86pc/io/mc/mcamd_drv.c, could be used for this? Also I don't think it is good if every other driver has his own functions to access the extended config space. The existing functions behind pci_putl_func etc. could probably be easily extended to allow ECS accesses. If I would make a patch to extend them, where should I send it for review and inclusion into OpenSolaris? Hans -- %SYSTEM-F-ANARCHISM, The operating system has been overthrown