Re: [PATCH] newsyslog - don't compress first log file
> How about using the flag "0" similar to that in newsyslog written by > Theodore Ts'o of MIT Project Athena: Sorry, I have to correct myself: The flag "0" appears in the enhanced version of newsyslog that is maintained by Greg A. Woods. Dirk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
strange KASSERT in _sleep()
hi
tsleep() maps to _sleep() with lock = NULL,
the _sleep() contains this:
KASSERT(timo != 0 || mtx_owned(&Giant) || lock != NULL ||
ident == &lbolt, ("sleeping without a lock"));
which simplifies for tsleep(foo, ...) where foo != lbolt to
"timo != 0 || mtx_owned(&Giant)"
why do I have to hold Giant or have timo != 0 when calling tsleep?
thnx for explanation
roman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] newsyslog - don't compress first log file
On Fri, August 10, 2007 18:13, David Wolfskill wrote: > > Biggest problem I can see (with what I want to accomplish) is how to > specify it in the config file. > We could extend the 'count' field to accept 'N+M'. N being the number of plain log files and M the number of compressed ones. This would also negate the need for a new flag. Joost. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] newsyslog - don't compress first log file
> We could extend the 'count' field to accept 'N+M'. N being the number of > plain log files and M the number of compressed ones. > > This would also negate the need for a new flag. It could also be done with a numerical flag "n" where n is a number that specifies the extension of the logfile up to which no compression should be done. An example configfile entry for 90 rotate logs and 40 uncompressed ones would look as follows: # logfilename [owner:group]mode count size when flags [/pid_file] [sig_num] /var/log/example.log644 89100 * J39 I already implemented that approach and am currently testing it. When finished, I will post a patch so that David can try it, but that will not happen before Sunday, because I am a little bit busy with other things. Most of the changes handle the compressed and uncompressed logs and it will be little work to modify it for the N+M count-field approach. Dirk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] newsyslog - don't compress first log file
On Sat, Aug 11, 2007 at 04:12:29PM +0200, Joost Bekkers wrote: > On Fri, August 10, 2007 18:13, David Wolfskill wrote: > > > > Biggest problem I can see (with what I want to accomplish) is how to > > specify it in the config file. > > > > We could extend the 'count' field to accept 'N+M'. N being the number of > plain log files and M the number of compressed ones. > > This would also negate the need for a new flag. Hmm... clever. :-) Given that bit of inspiration, I may see if I can do something useful in the next few days: thank you! Peace, david -- David H. Wolfskill [EMAIL PROTECTED] Anything and everything is a (potential) cat toy. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpIWGSq7ttck.pgp Description: PGP signature
Re: [PATCH] newsyslog - don't compress first log file
On Sat, Aug 11, 2007 at 04:39:42PM +0200, Dirk GOUDERS wrote: > > > We could extend the 'count' field to accept 'N+M'. N being the number of > > plain log files and M the number of compressed ones. > > > > This would also negate the need for a new flag. > > It could also be done with a numerical flag "n" where n is a number that > specifies the extension of the logfile up to which no compression > should be done. An example configfile entry for 90 rotate logs and 40 > uncompressed ones would look as follows: > > # logfilename [owner:group]mode count size when flags > [/pid_file] [sig_num] > /var/log/example.log 644 89100 * J39 > > I already implemented that approach and am currently testing it. > When finished, I will post a patch so that David can try it, but that > will not happen before Sunday, because I am a little bit busy with > other things. > > Most of the changes handle the compressed and uncompressed logs and it > will be little work to modify it for the N+M count-field approach. Ah -- well, then: by all means. I'm even more willing to test other folks' work than I am to hack away at code. :-} And since I had tested my own Perl script, I think I should be able to help out with this. :-) And "after Sunday" is not a problem at all: thank you! Peace, david -- David H. Wolfskill [EMAIL PROTECTED] Anything and everything is a (potential) cat toy. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpfc8mJfuTuF.pgp Description: PGP signature
IDE ultraDMA problem (hackers WAS via IDE controller problem) - SOLVED !!
*** Re-cap of problem: FreeBSD 6.2-STABLE was not recognizing the VT8237A south bridge ultraDMA ata controller on a P5VD2-X ASUS mobo. FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 4 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi_hpet0: iomem 0xfe80-0xfe8003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 2000 acpi0: Power Button (fixed) acpi0: reservation of fe80, 100 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: irq 27 at device 2.0 on pci0 pci2: on pcib2 nvidia0: mem 0xdc00-0xdcff,0xc000-0xcfff,0xdd00-0xddff irq 24 at device 0.0 on pci2 nvidia0: [GIANT-LOCKED] atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 15.0 on pci0 ata0: on atapci0 ata1: on atapci0 *** end of recap pciconf -lv gave me this clue: [EMAIL PROTECTED]:15:0: class=0x01018a card=0x81cf1043 chip=0x53371106 rev=0x07 hdr=0x00 vendor = 'VIA Technologies Inc' class = mass storage subclass = ATA after a long,long search, I found that chip id 0x53371106 belongs to SATA150 controller, not PATA !! Then I enabled all mass storage controllers on the board ( although no SATA drives present ), then two more ids showed up: chip=0x016a10de (jmicron SATA300) chip=0x05711106 <- thats it !! Then I went iinto /usr/src/sys/dev/ata/ata-pci.h and changed the line from #define ATA_VIA8237A0x05911106 to #define ATA_VIA8237A0x05711106 recompiled, install and BANG! nvidia0: mem 0xdc00-0xdcff,0xc000-0xcfff,0xdd00-0xddff irq 24 at device 0.0 on pci2 nvidia0: [GIANT-LOCKED] pcib3: irq 31 at device 3.0 on pci0 pci3: on pcib3 atapci0: port 0xcc00-0xcc07,0xc800-0xc803,0xc400-0xc407,0xc000-0xc003,0xbc00-0xbc0f mem 0xdfefe000-0xdfef irq 28 at device 0.0 on pci3 atapci0: AHCI Version 01.00 controller with 2 ports detected ata2: on atapci0 ata3: on atapci0 ata4: on atapci0 atapci1: port 0xfc00-0xfc07,0xf800-0xf803,0xf400-0xf407,0xf000-0xf003,0xec00-0xec0f,0xe800-0xe8ff irq 21 at device 15.0 on pci0 ata5: on atapci1 ata6: on atapci1 atapci2: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe400-0xe40f at device 15.1 on pci0 ata0: on atapci2 ata1: on atapci2 ad0: 114498MB at ata0-master UDMA100 ad1: 117246MB at ata0-slave UDMA133 ad2: 76351MB at ata1-master UDMA133 acd0: DVDR at ata1-slave UDMA66 Normal life returned :-D I dont know if this fix applies to ALL mobos that use VIA chipset (VT8237A) but it shure did to my ASUS mobo Thanks Wojciech Puchar and Sten Daniel Soersdal for your kind attention. -- ** //| //| Mario Lobo // |// | http://www.ipad.com.br // // ||| FreeBSD since 2.2.8 - 100% Rwindows-free ** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: strange KASSERT in _sleep()
Roman Divacky wrote this message on Sat, Aug 11, 2007 at 14:46 +0200:
> tsleep() maps to _sleep() with lock = NULL,
>
> the _sleep() contains this:
>
> KASSERT(timo != 0 || mtx_owned(&Giant) || lock != NULL ||
> ident == &lbolt, ("sleeping without a lock"));
>
>
> which simplifies for tsleep(foo, ...) where foo != lbolt to
> "timo != 0 || mtx_owned(&Giant)"
>
> why do I have to hold Giant or have timo != 0 when calling tsleep?
To prevent a deadlock.. It would be possible for you to miss your
wakeup if you don't have a lock (such as Giant) held... By forcing
a timeout, you guarantee that it will check the condition sometime
in the future...
--
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]"
