Re: bus_alloc_resource question
In message: <[EMAIL PROTECTED]> Chuck Tuffli <[EMAIL PROTECTED]> writes: : I'm having some trouble adding a bus resource and am hoping someone : can point out where I goofed. : : The host bus to a new x86 chipset has a memory mapped region in PCI : space that provides access to status and control registers. For a : driver to get access to this region, I figured it should call : bus_alloc_resource() the same as for any other memory mapped region. : This currently doesn't "just work" as the region is not a part of any : device's BARs. To add this region as a resource, I used : bus_set_resource() : : device_t dev; : uint32_t e_mem = 0xe000; : struct resource *ecfg_res; : : dev = pci_find_device(PCI_VENDOR_INTEL, ...); : bus_set_resource(dev, SYS_RES_MEMORY, e_mem, 0xe000, 0x1000); : : but a subsequent call to bus_alloc_resource() returns NULL : : ecfg_res = bus_alloc_resource(dev, SYS_RES_MEMORY, &e_mem, : 0, ~0, 1, RF_ACTIVE | RF_SHAREABLE); : : A call to bus_get_resource() shows that the resource did get set as : the call returns the correct starting address and count. Is there : something else that needs to happen between the set and the alloc? Is : this even the correct approach? Thanks in advance! Generally, one doesn't need to set the resource value. Doing so usually indicates the presence of some bug in the system. Also, just because you set a value doesn't mean that it will be honored. It is entirely possible that you picked a bogus resource and the system can't give it to you. The reasons for this are many: it could be in use by another device, it could be that it exceeds the range of the resource, it could be that it failed sanity checks. On the PCI bus, these sanity checks include 'can the address make it through the bridges between it and the host bridge'. If the answer is no, you'll not be able to allocate things. I'd just remove the bus_set_resource entirely. It is almost never needed for pci drivers. There is a bug in your code however: : uint32_t e_mem = 0xe000; : ecfg_res = bus_alloc_resource(dev, SYS_RES_MEMORY, &e_mem, : 0, ~0, 1, RF_ACTIVE | RF_SHAREABLE); The third argument is the rid. For the PCI bus, this is the offset in the config space of the BAR you wish to map/allocate. 0xe000 is not a valid offset into the config space. Numbers like 0x10 and 0x14 are valid offsets. Chances are this is the source of your problems. You may wish to remove the RF_SHAREABLE as well, since most device drivers aren't designed to share access to their hardware with other devices. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
bus_alloc_resource question
I'm having some trouble adding a bus resource and am hoping someone can point out where I goofed. The host bus to a new x86 chipset has a memory mapped region in PCI space that provides access to status and control registers. For a driver to get access to this region, I figured it should call bus_alloc_resource() the same as for any other memory mapped region. This currently doesn't "just work" as the region is not a part of any device's BARs. To add this region as a resource, I used bus_set_resource() device_t dev; uint32_t e_mem = 0xe000; struct resource *ecfg_res; dev = pci_find_device(PCI_VENDOR_INTEL, ...); bus_set_resource(dev, SYS_RES_MEMORY, e_mem, 0xe000, 0x1000); but a subsequent call to bus_alloc_resource() returns NULL ecfg_res = bus_alloc_resource(dev, SYS_RES_MEMORY, &e_mem, 0, ~0, 1, RF_ACTIVE | RF_SHAREABLE); A call to bus_get_resource() shows that the resource did get set as the call returns the correct starting address and count. Is there something else that needs to happen between the set and the alloc? Is this even the correct approach? Thanks in advance! -- Chuck Tuffli Agilent Technologies, Storage Area Networking ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question for C++ Experts
On 2004-07-26 at 21:55:32 Ryan Sommers wrote: > The problem I am running into is that it seems to be illegal to call > a pure virtual function from an abstract base contructor. This is because you shouldn't call virtual functions from constructors, unless you know what you're doing. :) Try using exceptions, or two-phase initialization. And read a C++ FAQ for more info, i.e.: http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.3 There's lots more in there, also explaining your other questions. But this is quite offtopic for this list... pgpTB6DXp2bjZ.pgp Description: PGP signature
Question for C++ Experts
Pardon my sending this to a FreeBSD list. After searching I couldn't find any other good mailings lists devoted to C++ and this was the only source I knew of that might have someone that could answer my question. I'm working on a project that uses about 3 different coordinate systems and all are closely related. The only differences are in the bounds and representation. As a way to represent all of these I came up with a base class representing the general case and then derived classes for all the specific systems. As part of my class I use constructors that take the coordinates as inputs. As a means of bounds checking I declared a pure virtual function that checks whether it is within the valid bounds of the derived class. The problem I am running into is that it seems to be illegal to call a pure virtual function from an abstract base contructor. I'm not sure exactly why this would be considered an eror; from what I can think of the dynamic binding would be no different than for a binding in a non-constructor function. Anyone know of any tricks to get around this? Or other methods that might allow me to do the correct bounds checking in the constructor as opposed to delaying it to a second 'init' type call? Ryan Sommers [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: disk recovery help
On Thu, 22 Jul 2004, Peter Jeremy wrote: > >command does, but they are fairly certain that it writes it's config at > >the end of the disk, then zeros it from the outside in. > > Which puts an upper limit on the amount of damage done. The only > difficulty with this is that (ISTR) your filesystem begins at the > beginning of the array so the primary superblock should be the first > thing over-written - and fsck would whinge loudly about that. I did get confirmation from Adaptec that it does go from the outside sectors in. > >grabbed the dd "image" before that. An fsck on the problem partition ran > >for 12 hours and I don't know how far along it was. > > Ctrl-T (aka SIGINFO) is your friend - fsck will tell you how far > through its current phase it is. Ah. Hence the reference to stty in the fsck manpage. Thanks! > I was hoping it would also locate all the superblocks - which > would let you verify that the structure looked reasonably sane. > You might also try fsdb(8) - though I think it relies on the primary > superblock being sane. I ended up using sysutils/ffsrecov to grab the alternate superblocks. I have a reasonably OK fsck'd filesystem mounted now. I have another copy to work on, and my question there is this: When you run fsck it creates a "lost+found" directory to put files that are unreferenced anywhere (I think that's the terminology). At some point during the fsck, it starts spitting errors about there not being enough space in "lost+found". Is there any way to remedy that problem? Is there some way to "grow" the filesystem *before* fsck-ing it? The only bit about this in the fsck manpage is the following: "If the lost+found directory does not exist, it is created. If there is insufficient space its size is increased." Thanks to everyone for your help so far. This has been a good learning experience. Charles > Good luck. > > -- > Peter Jeremy > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Simulate device-file in userland?
Dear Sirs, is it appreciated if i introduce myself first? if so, please let me know. i was wondering if it is possible to simulate a device-file ( for example a serial port or videograbbing device ) in userland? i have looked at mkfifo, but i think that does not suit my needs: i am interested in ioctl calls as well. are there any examples in ports? is this possible at all? regards, Jan___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: "-exit" option for find(1)
On Fri, Jul 16, 2004 at 12:23:41AM -0700, Alfred Perlstein wrote: > I'm up too late, this doesn't work because find returns > success whenever it successfully runs thought everything. > > Perhaps the primary change to just "-exit" which would > make find exit successfully, and if the primary is never > encountered (ie. our find logic never hits it) find would > exit with a non-zero exit status? > > Ideas? Better ideas? > > The reason I want this is to avoid extracting a tarball > over a directory that has files in it that are newer than > the tarball. > > Neither tar nor find seem to make this easy... > [ `find . -type f -newer ../src.tar.gz |head -1 |wc -l` -eq 0 ] && echo hi Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgptKBBVmt0E5.pgp Description: PGP signature
