Re: Running a shell script on becoming the CARP master?
On Saturday 26 November 2005 16:14, Matthew Hagerty wrote: Are there any hooks into CARP to run a shell script when a machine becomes the master? Also, is there a way to force a machine to become the master without powering off the current master (for example to do maintenance on the current master)? net/ifstated from ports might be what you are looking for. -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpkEHnQYn8sF.pgp Description: PGP signature
Re: Writing a driver for a card reader controller - how?
to find on the mmc web site. These registers are standard, and I anticipate that FreeBSD will have a mmc-bus layer that interacts with these things. My initial take on the newbus hierarchy will look something like: [ ... ] Where each bridge driver takes care of providing a standard inteface to the mmcbus layer. That layer would provide the means to do transfers and the like. mmcf would be the interface presented to the user for mmc flash cards. So I suppose I put my driver hacking attempts on the back burner for now and wait for that mmc framework to be designed? I still wonder why I cannot really talk with the chip in my notebook, though. Maybe one day someone crafts a driver for it where I can see how it's done the right way... Best wishes, Thiemo -- Query a PGP key server (e.g. http://www.pgp.net/) for my public key 41068629. Strange sender address? Please see http://www.thiemo.net/misc/list-mail.shtml ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible way to distribute NFS?
mike wrote: If someone could write an NFS client using FUSE (perhaps?) and have it integrate with memcached[1], couldn't that basically allow for n+1 scaling I have had a similar idea to do in FUSE for some time now, but I'm waiting until I can spare the time to do it and the FUSE system becomes more stable (which should happen soon). Also note that, if done with FUSE, it will be slower than kernel code. Maybe not by much (http://creo.hu/pipermail/fuse4bsd-devel/2005-October/09.html), but it's not yet clear how much. The problem I would try to solve is that of having single-writer- multiple-readers setup (writes go through one machine, get distributed to other machines, reads can go wherever), and without using NFS (though it's a good idea now that you mention it :) ), so it's maybe not what you need. If understand your suggestion correctly, all NFS-like traffic would pass through a single machine, which doesn't sound good speed-wise...? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Loading gzipped mfsroot
I've seen a lot of examples where peeple load gzipped mfsroot images and everything looks fine for them, but not for me. It loads uncompressed image and boots ok, it loads compressed image and does not uncompress it and then tries to mount ufs directly on it which fails ofcourse. As I saw bay default loader(and pxeboot porbably - its a diskless machine which boots over ethernet) have LOADER_GZIP_SUPPORT defined so I think I should have gzip support in loader. Here is the loader.conf: rootfs_load=YES rootfs_name=dlroot.gz rootfs_type=mfs_root and its FreeBSD 5.4-STABLE about a week old. I'm out of ideas right now :(. Regards ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Loading gzipped mfsroot
From: Iasen Kostov [EMAIL PROTECTED] I've seen a lot of examples where peeple load gzipped mfsroot images and everything looks fine for them, but not for me. It loads uncompressed image and boots ok, it loads compressed image and does not uncompress it and then tries to mount ufs directly on it which fails ofcourse. As I saw bay default loader(and pxeboot porbably - its a diskless machine which boots over ethernet) have LOADER_GZIP_SUPPORT defined so I think I should have gzip support in loader. Here is the loader.conf: rootfs_load=YES rootfs_name=dlroot.gz rootfs_type=mfs_root I've not users this in quite a while, so I may be wrong here, but I think what you need is: rootfs_name=dlroot If gzip support is compiled in, it will automatically try to fetch dlroot.gz first and if it succeeds, it will uncompress and use it. The way you have configured it, it tries dlroot.gz.gz, which fails, so then it tried to load dlroot.gz as an uncompressed file. David ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Loading gzipped mfsroot
On Mon, 2005-11-28 at 09:18 -0500, David S. Madole wrote: From: Iasen Kostov [EMAIL PROTECTED] I've seen a lot of examples where peeple load gzipped mfsroot images and everything looks fine for them, but not for me. It loads uncompressed image and boots ok, it loads compressed image and does not uncompress it and then tries to mount ufs directly on it which fails ofcourse. As I saw bay default loader(and pxeboot porbably - its a diskless machine which boots over ethernet) have LOADER_GZIP_SUPPORT defined so I think I should have gzip support in loader. Here is the loader.conf: rootfs_load=YES rootfs_name=dlroot.gz rootfs_type=mfs_root I've not users this in quite a while, so I may be wrong here, but I think what you need is: rootfs_name=dlroot If gzip support is compiled in, it will automatically try to fetch dlroot.gz first and if it succeeds, it will uncompress and use it. The way you have configured it, it tries dlroot.gz.gz, which fails, so then it tried to load dlroot.gz as an uncompressed file. David Thanks a lot ! That do the trick :) It will realy be good if this is documented somewhere - probably in loader(8) manual page ... And will save people some hours of blessing loader(8) :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: to list all the devices in freebsd definition analyse
kylin [EMAIL PROTECTED] writes: M. Warner Losh [EMAIL PROTECTED] writes: devinfo -v devinfo is different with pciconf devinfo depends on the sysctl mechanism while pciconf ioctl the /dev/pci who will directly read the pci configuration space there is more in life than pci. devclass is the information about all instances of the device. device_t is an instance of the device. The only difference between a bus and a device is that a bus has children. but pcib and cbb still have pci or cardbus as there children ,and pcib and cbb is bridge rather than bus :( i am puzzle with the definition:( as far as the kernel is concerned, any devices that other devices attach to is a bus. we who r about to die,salute u! please learn to spell. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: to list all the devices in freebsd definition analyse
my god ,mercy me On 11/28/05, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: kylin [EMAIL PROTECTED] writes: M. Warner Losh [EMAIL PROTECTED] writes: devinfo -v devinfo is different with pciconf devinfo depends on the sysctl mechanism while pciconf ioctl the /dev/pci who will directly read the pci configuration space there is more in life than pci. i agree:) devclass is the information about all instances of the device. device_t is an instance of the device. The only difference between a bus and a device is that a bus has children. but pcib and cbb still have pci or cardbus as there children ,and pcib and cbb is bridge rather than bus :( i am puzzle with the definition:( as far as the kernel is concerned, any devices that other devices attach to is a bus. no .device_get_parent of a pci bus we get pcib we who r about to die,salute u! please learn to spell. come from the gladiator:In ancient rome, the glorious gladiator show their respect to the audience whit the words:we who are about to die salute you but thank u for your advice all the same :) -- we who r about to die,salute u! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
puzzle about the pci_add_child
i am reading the pci code of freeBSD 53 ,and come to the puzzle of
pci_add_child.
1
why should we =09pci_cfg_save(dinfo-cfg.dev, dinfo, 0); after we have
already fill the cfg in pci_read_device ?
2
what 's the purpose of the function couple
pci_cfg_save(dinfo-cfg.dev, dinfo, 0);
pci_cfg_restore(dinfo-cfg.dev, dinfo)
below is the function ,thank u
pci_add_child(device_t bus, struct pci_devinfo *dinfo)
{
device_t pcib;
pcib = device_get_parent(bus);
dinfo-cfg.dev = device_add_child(bus, NULL, -1);//NULLmeans no
devclass to create
// for pci bus refers to pci device node
device_set_ivars(dinfo-cfg.dev, dinfo);
pci_cfg_save(dinfo-cfg.dev, dinfo, 0);//for what read and write?
pci_cfg_restore(dinfo-cfg.dev, dinfo);//not store ,but REstore ,power related
pci_add_resources(pcib, bus, dinfo-cfg.dev);//see resource are bridge related
pci_print_verbose(dinfo);
...
}
--
we who r about to die,salute u!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Writing a driver for a card reader controller - how?
On Thursday 24 November 2005 01:26 pm, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Thiemo Nordenholz [EMAIL PROTECTED] writes: : Hi Warner, : : to be set. Can you send me a pointer to the winbond datasheet you are : using? IIRC, this chip has an odd API since it appears to be derived : : As I have to wait for some spare time before trying to use the hints I : have received here, for now I can only answer that question - I found a : datasheet at : http://www.winbond.com/e-winbondhtm/partner/PDFresult.asp?Pname=863 which : is what I try to work with. (That page sends a file PDFresult.asp, : which is actually a PDF.) I've read through this pdf. As far as I can find, it just talks about how to setup the base address for each of the sets of registers without actually talking about the sets of registers themselves. Nor can I find in the document a pointer to the different register sets. Do you have one of those as well? It looks fairly easy to program this device's base addresses or inquire what they are. It is done in much the same way that super I/O chips are programmed. For an ACPI device you want to use _PRS and _SRS. _PRS will give you a list of candidate resource sets, possibly in groups via DPF tags. You then build a resource and do an _SRS to set it. The problem is that our ACPI bus isn't smart enough to allocate resources for a device when bus_alloc_resource() is called to choose available resources when a device is not configured. This is similar to how you fixed the PCI bus recently to allocate resources for BARs that weren't already allocated by the BIOS. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libutil properties_read() bug: patch for review
On Wednesday 23 November 2005 07:14 pm, Antony Mawer wrote: Hi, I recently hit upon a bug in sysinstall, getting an Invalid realloc size of 0 error that caused sysinstall to terminate. I eventually tracked it down to a bug in the properties_read() function of libutil, which occurs only when reading a properties file of 4096 bytes or greater. This is because libutil discards its current state when the buffer runs out (4096 bytes) and it must refill the buffer, causing the properties file (*.inf) to be incorrectly read. I've made a patch that's attached to the PR I filed, PR 89181, but was hoping to get some extra eyes on the patch to make sure that there's nothing amiss with the patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=89181 Hopefully someone can review this and see about getting it committed for 6.1! I just committed it to HEAD. It should be MFC'd in time for both 5.5 and 6.1. Thanks! -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pc card on watchguard firebox II
On Sunday 27 November 2005 11:49 pm, Anthony Mattke wrote: I have a WatchGuard Firebox II that I've been working on turning into a decent router. I see many people have installed monowall (http://m0n0.ch/wall/) on these boxes with good success. I would be done myself unless I was setting up a wireless bridge. These boxes are basicly custom pentium 200's with 3 ethernet ports, a few serial ports, 2 pcmcia card slots, a 44pin ide header, a keyboard header, and 2 backwards facing pci slots. The problem I am having is with getting a pc card to be detected, it knows they're there, it just wont register them. First off, I'm new to BSD. Second, I know this is not straight up BSD, but if given direction I can make anything happen that needs to for testing, I have a 5.3 box setup for testing, altho I'm having trouble getting it to boot on the firebox ( i need to recompile and disabe psm0 detection) Anyway, this is what I'm seeing. pci_cfgintr: can't route an interrupt to 0:16 INTA pcic0: TI PCI-1225 PCI-CardBus Bridge at device 16.0 on pci0 pcic0: PCI Memory allocated: 0x8800 pci_cfgintr: can't route an interrupt to 0:16 INTA pcic0: No PCI interrupt routed, trying ISA. pcic0: Polling mode pcic0: TI12XX PCI Config Reg: [ring enable][speaker enable][pwr save][CSC serial isa irq] pccard0: PC Card 16-bit bus (classic) on pcic0 Ask Warner about this. It looks like your BIOS is rather lame such that it doesn't set an IRQ for your card slot and doesn't tell the OS how to figure out which IRQ to use either. pcic0 might really want an interrupt to work correctly on this system. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Writing a driver for a card reader controller - how?
In message: [EMAIL PROTECTED] John Baldwin [EMAIL PROTECTED] writes: : On Thursday 24 November 2005 01:26 pm, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : : Thiemo Nordenholz [EMAIL PROTECTED] writes: : : Hi Warner, : : : : to be set. Can you send me a pointer to the winbond datasheet you are : : using? IIRC, this chip has an odd API since it appears to be derived : : : : As I have to wait for some spare time before trying to use the hints I : : have received here, for now I can only answer that question - I found a : : datasheet at : : http://www.winbond.com/e-winbondhtm/partner/PDFresult.asp?Pname=863 which : : is what I try to work with. (That page sends a file PDFresult.asp, : : which is actually a PDF.) : : I've read through this pdf. As far as I can find, it just talks about : how to setup the base address for each of the sets of registers : without actually talking about the sets of registers themselves. Nor : can I find in the document a pointer to the different register sets. : Do you have one of those as well? It looks fairly easy to program : this device's base addresses or inquire what they are. It is done in : much the same way that super I/O chips are programmed. : : For an ACPI device you want to use _PRS and _SRS. _PRS will give you a list : of candidate resource sets, possibly in groups via DPF tags. You then build : a resource and do an _SRS to set it. The problem is that our ACPI bus isn't : smart enough to allocate resources for a device when bus_alloc_resource() is : called to choose available resources when a device is not configured. This : is similar to how you fixed the PCI bus recently to allocate resources for : BARs that weren't already allocated by the BIOS. Ah, I see. Sounds like time to jump into the ACPI code and do someting similar... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Loading gzipped mfsroot
On Mon, Nov 28, 2005 at 04:38:11PM +0200, Iasen Kostov wrote: On Mon, 2005-11-28 at 09:18 -0500, David S. Madole wrote: From: Iasen Kostov [EMAIL PROTECTED] I've seen a lot of examples where peeple load gzipped mfsroot images and everything looks fine for them, but not for me. It loads uncompressed image and boots ok, it loads compressed image and does not uncompress it and then tries to mount ufs directly on it which fails ofcourse. As I saw bay default loader(and pxeboot porbably - its a diskless machine which boots over ethernet) have LOADER_GZIP_SUPPORT defined so I think I should have gzip support in loader. Here is the loader.conf: rootfs_load=YES rootfs_name=dlroot.gz rootfs_type=mfs_root I've not users this in quite a while, so I may be wrong here, but I think what you need is: rootfs_name=dlroot If gzip support is compiled in, it will automatically try to fetch dlroot.gz first and if it succeeds, it will uncompress and use it. The way you have configured it, it tries dlroot.gz.gz, which fails, so then it tried to load dlroot.gz as an uncompressed file. David Thanks a lot ! That do the trick :) It will realy be good if this is documented somewhere - probably in loader(8) manual page ... And will save people some hours of blessing loader(8) :) loader(8) has no business documenting this; it's already documented (though not too verbose) in the libstand(3) manpage. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpcn5ZjfD1SF.pgp Description: PGP signature
Re: to list all the devices in freebsd definition analyse
kylin wrote this message on Tue, Nov 29, 2005 at 00:04 +0800: devclass is the information about all instances of the device. device_t is an instance of the device. The only difference between a bus and a device is that a bus has children. but pcib and cbb still have pci or cardbus as there children ,and pcib and cbb is bridge rather than bus :( i am puzzle with the definition:( as far as the kernel is concerned, any devices that other devices attach to is a bus. no .device_get_parent of a pci bus we get pcib we who r about to die,salute u! so?? In FreeBSD land, a device_t is a bus if it has one or more children.. To put it more simply, all busses are devices... As for your example of device_get_parent.. you don't realize that the pci bus is also a device... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: puzzle about the pci_add_child
In message: [EMAIL PROTECTED] kylin [EMAIL PROTECTED] writes: : i am reading the pci code of freeBSD 53 ,and come to the puzzle of :pci_add_child. :1 : why should we =09pci_cfg_save(dinfo-cfg.dev, dinfo, 0); after we have :already fill the cfg in pci_read_device ? It hasn't been completely filled in by pci_read_device. :2 :what 's the purpose of the function couple :pci_cfg_save(dinfo-cfg.dev, dinfo, 0); :pci_cfg_restore(dinfo-cfg.dev, dinfo) :below is the function ,thank u Power state gets set to D0 as a side effect so that the device is live for the probe. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pc card on watchguard firebox II
In message: [EMAIL PROTECTED] John Baldwin [EMAIL PROTECTED] writes: : On Sunday 27 November 2005 11:49 pm, Anthony Mattke wrote: : I have a WatchGuard Firebox II that I've been working on turning into : a decent router. I see many people have installed monowall : (http://m0n0.ch/wall/) on these boxes with good success. I would be : done myself unless I was setting up a wireless bridge. : : These boxes are basicly custom pentium 200's with 3 ethernet ports, a : few serial ports, 2 pcmcia card slots, a 44pin ide header, a keyboard : header, and 2 backwards facing pci slots. : : The problem I am having is with getting a pc card to be detected, it : knows they're there, it just wont register them. : First off, I'm new to BSD. : Second, I know this is not straight up BSD, but if given direction I : can make anything happen that needs to for testing, I have a 5.3 box : setup for testing, altho I'm having trouble getting it to boot on the : firebox ( i need to recompile and disabe psm0 detection) : : Anyway, this is what I'm seeing. : : pci_cfgintr: can't route an interrupt to 0:16 INTA : pcic0: TI PCI-1225 PCI-CardBus Bridge at device 16.0 on pci0 : pcic0: PCI Memory allocated: 0x8800 : pci_cfgintr: can't route an interrupt to 0:16 INTA : pcic0: No PCI interrupt routed, trying ISA. : pcic0: Polling mode : pcic0: TI12XX PCI Config Reg: [ring enable][speaker enable][pwr : save][CSC serial isa irq] : pccard0: PC Card 16-bit bus (classic) on pcic0 : : Ask Warner about this. It looks like your BIOS is rather lame such that it : doesn't set an IRQ for your card slot and doesn't tell the OS how to figure : out which IRQ to use either. pcic0 might really want an interrupt to work : correctly on this system. The first thing I notie is that pcic0 is OLDCARD. You should be using NEWCARD since I've forgotten all about OLDCARD. If you are using 4.x, then try 6.0. The interrupt routing code is much better there. 200MHz pentium is right about the time when PCI BIOS was newish, so maybe the BIOS in this machine isn't setting up the PIR correctly. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
